Good morning

-- Good day. Please forgive me for using this means to reach you but I can't think of any other way of letting you know the urgent matter at hand. A national of your country who happens to be a customer of our bank where I work (Ecobank Ghana) was a victim of an auto crash in 2017 and he left behi

good morning

-- Hello Can i talk to you please? Amanda

Re: Good Morning.

INDICATING THIS CODE (FRBNYATM-2020) YOUR FUND ($10.5MILLION) OFFICIAL NOTICE: this is to notify you that Series of meetings have been held since last week with the Secretary General of the United Nations, which ended yesterday been Thursday 22st Dated of October 2020,It is obvious that you h

Good Morning!

-- Greetings, I Mr Bill T, did you Receive the (FUND), that was paid to you? Let me know with your full name:... immediately, Sincerely Yours, Respectfully, Mr Bill T Winters, Group Chief Executive Officer & Executive Director,

Good morning

-- Hello. Greetings dd you received my previous email?

??>> Good Morning to You>>>><

Good Day, Hope you are doing great Today.I have a proposed business deal that will benefit both parties. This is legitimate,legal and your REPUTATION will not be compromised.Please Reply to me only if you are interested and consider your self capable for details. Sincerely, Peter OWEN

Good Morning!

Dear Sir/Madam. I am, MR.Abd Manaf,I have (15.5 M Dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Yours Sincerely,

Good Morning

Thanks for your urgent response. My name is Stella Adams, a personal secretary to John Paul. My boss left an envelope which contain bank card worth of $800,000.00. The bank card will be used at any ATM machine across the globe. Courier delivery company will deliver the parcel to your doorstep. All

Good Morning

Good Morning, I am Victoria Benson writing you in regards of my family inheritance which is been deposited for safe keeping in a private security company.Further more the total amount of my funds is 2.5 million dollars clean and spendable. And i was told to get a foreign beneficary who will

Morning

Hello; kindly see the attached my proposal Charities donation. Mrs. Joy Smith Johnson.rtf Description: RTF file

Re: droid 4: no sound in the morning

On Tue 2018-07-10 12:59:10, Pavel Machek wrote: > Hi! > > I attempted to use droid 4 as an alarm clock, but got no sound in the > morning. > > Log said: > > [78798.682830] omap-mcbsp 40124000.mcbsp: CLKS: could not > clk_set_parent() to prcm_fck > [78803.561767] o

droid 4: no sound in the morning

Hi! I attempted to use droid 4 as an alarm clock, but got no sound in the morning. Log said: [78798.682830] omap-mcbsp 40124000.mcbsp: CLKS: could not clk_set_parent() to prcm_fck [78803.561767] omap-mcbsp 40126000.mcbsp: CLKS: could not clk_set_parent() to prcm_fck Could it be related

Good morning,

How are you today? it is just that I sent you this message last week but you fail to reply, I have a (B/F) information to share with you kindly get back to me for more information. Regards. Ms. Annabelle Edo.

Good Morning !

Good Morning , I have a project i would like to bring to you and i want you to help me discuss it. please let me know if you will be available for this project. Thanks

RE: Good Morning

I Liliane authenticate is Donating 3.5M USD from My Net-worth to you, Email me on;lianebc...@rogers.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vg

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

On Fri, 19 Oct 2007 12:18:19 +0200 Mike Galbraith wrote: > On Fri, 2007-10-19 at 04:49 +0200, Mike Galbraith wrote: > > On Thu, 2007-10-18 at 23:33 +0100, Samuel Thibault wrote: > > > Hi, > > > > > > Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit : > > > > The winner of a very long g

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

On Fri, 2007-10-19 at 09:55 +0100, Samuel Thibault wrote: > Just to make sure, could you check in System.map that accent_table is > correctly 256*3*4=3072 bytes long? See mail I just sent. A day a half wasted here. Sorry for however much time you wasted on this. -Mike - To unsubscribe

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

On Fri, 2007-10-19 at 04:49 +0200, Mike Galbraith wrote: > On Thu, 2007-10-18 at 23:33 +0100, Samuel Thibault wrote: > > Hi, > > > > Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit : > > > The winner of a very long git bisect session: > > > > > > unicode diacritics support > > >

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

Just to make sure, could you check in System.map that accent_table is correctly 256*3*4=3072 bytes long? Samuel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

On Thu, 2007-10-18 at 23:33 +0100, Samuel Thibault wrote: > Hi, > > Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit : > > The winner of a very long git bisect session: > > > > unicode diacritics support > > Uh, I fail to see how that could have an impact, I've again checked the >

Re: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

Hi, Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit : > The winner of a very long git bisect session: > > unicode diacritics support Uh, I fail to see how that could have an impact, I've again checked the boundaries, it looks fine, please people have a look. Could you try somethi

[bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

On Thu, 2007-10-18 at 06:25 +0200, Mike Galbraith wrote: > Greetings, > > Freshly pulled tree oopes per $subject. > > [ 114.714335] BUG: unable to handle kernel NULL pointer dereference at > virtual address 0031 > [ 114.732810] printing eip: c03332ff *pde = > [ 114.747614] Oops:

[microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

Greetings, Freshly pulled tree oopes per $subject. [ 114.714335] BUG: unable to handle kernel NULL pointer dereference at virtual address 0031 [ 114.732810] printing eip: c03332ff *pde = [ 114.747614] Oops: [#1] PREEMPT SMP [ 114.761320] Modules linked in: microcode snd_s

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 8/6/07, Nick Piggin <[EMAIL PROTECTED]> wrote: [...] > > this completely ignores the use case where the > > swapping was exactly the > > right thing to do, but memory has been freed up from > > a program exiting so > > that you couldnow fill that empty ram with data that > > was swapped out. > >

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

--- [EMAIL PROTECTED] wrote: > On Mon, 6 Aug 2007, Nick Piggin wrote: > > > [EMAIL PROTECTED] wrote: > >> On Sun, 29 Jul 2007, Rene Herman wrote: > >> > >> > On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote: > >> > > >> > > I agree that tinkering with the core VM code > should not be done >

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Mon, 6 Aug 2007, Nick Piggin wrote: [EMAIL PROTECTED] wrote: On Sun, 29 Jul 2007, Rene Herman wrote: > On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote: > > > I agree that tinkering with the core VM code should not be done > > lightly, > > but this has been put through the proper pro

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

[EMAIL PROTECTED] wrote: On Sun, 29 Jul 2007, Rene Herman wrote: On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote: I agree that tinkering with the core VM code should not be done lightly, but this has been put through the proper process and is stalled with no hints on how to move forward.

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

Hi! > > That would just save reading the directories. Not sure > > it helps that much. Much better would be actually if it didn't stat the > > individual files (and force their dentries/inodes in). I bet it does that > > to > > find out if they are directories or not. But in a modern system it

Re: Woke up to a crashed kernet this morning - nVidia is crap

On Thu, Aug 02, 2007 at 07:46:49AM -0700, Marc Perkel wrote: > OK - so the driver I downloaded from nVidia to fix > their problem I was having with the video installed > drivers for everything? I'm really getting to dislike > nVidia. It installs a kernel module just for the video card. Nothing el

Re: Woke up to a crashed kernet this morning - nVidia is crap

OK - so the driver I downloaded from nVidia to fix their problem I was having with the video installed drivers for everything? I'm really getting to dislike nVidia. --- Michal Piotrowski <[EMAIL PROTECTED]> wrote: > > Nvidia binary crap > > "When you are using a binary driver, the kernel >

Woke up to a crashed kernet this morning

Found this in the log. Running 2.6.22,1,41,fc7 - I had just upgraded the kernel last night using yum. And - I was running a lot of backups using rsync and was backing up to a usb connected drive. I'm not sure which event triggered it but I'm guessing the latter in that it's something I rarely do us

Re: [ck] Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

Matthew Hawkins wrote: updatedb by itself doesn't really bug me, its just that on occasion its still running at 7am You should start it earlier then - assuming it doesn't already start at the earliest opportunity? Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Sun, 29 Jul 2007, Rene Herman wrote: On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote: I agree that tinkering with the core VM code should not be done lightly, but this has been put through the proper process and is stalled with no hints on how to move forward. It has not. Concerns that

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Sunday 29 July 2007 16:00:22 Ray Lee wrote: > On 7/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote: > > If the problem is reading stuff back in from swap at the *same time* > > that the application is reading stuff from some user file system, and if > > that user file system is on the same drive a

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote: > Ray wrote: > > Ah, so in a normal scenario where a working-set is getting faulted > > back in, we have the swap storage as well as the file-backed stuff > > that needs to be read as well. So even if swap is organized perfectly, > > we're still s

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

Ray wrote: > Ah, so in a normal scenario where a working-set is getting faulted > back in, we have the swap storage as well as the file-backed stuff > that needs to be read as well. So even if swap is organized perfectly, > we're still seeking. Damn. Perhaps this applies in some cases ... perhaps.

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote: > If the problem is reading stuff back in from swap at the *same time* > that the application is reading stuff from some user file system, and if > that user file system is on the same drive as the swap partition > (typical on laptops), then inter

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

4) layout swap nicely 5) pre-fetch a favorite set of apps Stumble out of bed in the morning, press 'wake-up', start boiling the water for your coffee, and in another ten minutes, one is ready to rock and roll. In case Andrew is so bored he read this far -- yes this wake-up sounds like

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/29/2007 07:52 PM, Ray Lee wrote: Well, that doesn't match my systems. My laptop has 400MB in swap: Which in your case is slightly more than 1/3 of available swap space. Quite a lot for a desktop indeed. And if it's more than a few percent fragmented, please fix current swapout instead

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/29/07, Rene Herman <[EMAIL PROTECTED]> wrote: > On 07/29/2007 07:19 PM, Ray Lee wrote: > For me, it is generally the case yes. We are still discussing this in the > context of desktop machines and their problems with being slow as things > have been swapped out and generally I expect a desktop

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

> > Is that generally the case on your systems? Every linux system I've > > run, regardless of RAM, has always pushed things out to swap. > > For me, it is generally the case yes. We are still discussing this in the > context of desktop machines and their problems with being slow as things > hav

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/29/2007 07:19 PM, Ray Lee wrote: The program is not a real-world issue and if you do not consider it a useful boundary condition either (okay I guess), how would log structured swap help if I just assume I have plenty of free swap to begin with? Is that generally the case on your systems

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/29/07, Rene Herman <[EMAIL PROTECTED]> wrote: > On 07/29/2007 06:04 PM, Ray Lee wrote: > >> I am very aware of the costs of seeks (on current magnetic media). > > > > Then perhaps you can just take it on faith -- log structured layouts > > are designed to help minimize seeks, read and write. >

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/29/2007 06:04 PM, Ray Lee wrote: I am very aware of the costs of seeks (on current magnetic media). Then perhaps you can just take it on faith -- log structured layouts are designed to help minimize seeks, read and write. I am particularly bad at faith. Let's take that stupid program t

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/29/07, Rene Herman <[EMAIL PROTECTED]> wrote: > On 07/29/2007 05:20 PM, Ray Lee wrote: > This seems to be now fixing the different problem of swap-space filling up. > I'm quite willing to for now assume I've got plenty free. I was trying to point out that currently, as an example, memory that

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/29/2007 05:20 PM, Ray Lee wrote: I understand what log structure is generally, but how does it help swapin? Look at the swap out case first. Right now, when swapping out the kernel places whatever it can wherever it can inside the swap space. The closer you are to filling your swap spac

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/29/07, Rene Herman <[EMAIL PROTECTED]> wrote: > On 07/29/2007 04:58 PM, Ray Lee wrote: > > On 7/29/07, Rene Herman <[EMAIL PROTECTED]> wrote: > >> Right over my head. Why does log-structure help anything? > > > > Log structured disk layouts allow for better placement of writeout, so > > that y

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/29/2007 04:58 PM, Ray Lee wrote: On 7/29/07, Rene Herman <[EMAIL PROTECTED]> wrote: On 07/29/2007 03:12 PM, Alan Cox wrote: More radically if anyone wants to do real researchy type work - how about log structured swap with a cleaner ? Right over my head. Why does log-structure help

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/29/07, Rene Herman <[EMAIL PROTECTED]> wrote: > On 07/29/2007 03:12 PM, Alan Cox wrote: > > More radically if anyone wants to do real researchy type work - how about > > log structured swap with a cleaner ? > > Right over my head. Why does log-structure help anything? Log structured disk lay

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/29/2007 03:12 PM, Alan Cox wrote: What are the tradeoffs here? What wants small chunks? Also, as far as I'm aware Linux does not do things like up the granularity when it notices it's swapping in heavily? That sounds sort of promising... Small chunks means you get better efficiency of me

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote: And now you do it again :-) There is no conclusion -- just the inescapable observation that swap-prefetch was (or may have been) masking the problem of GNU locate being a program that noone in their right mind should be using. isn't your concl

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

> Contrived thing and all, but what it does do is show exactly how bad seeking > all over swap-space is. If you push it out before hitting enter, the time it > takes easily grows past 10 minutes (with my 768M) versus sub-second (!) when > it's all in to start with. Think in "operations/second"

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

Andi wrote: > GNU sort uses a merge sort with temporary files on disk. Not sure > how much it keeps in memory during that, but it's probably less > than 150MB. If I'm reading the source code for GNU sort correctly, then the following snippet of shell code displays how much memory it uses for its

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Sun, 29 Jul 2007, Rene Herman wrote: On 07/28/2007 11:00 PM, [EMAIL PROTECTED] wrote: > many -mm users use it anyway? He himself said he's not convinced of > usefulness having not seen it help for him (and notice that most > developers are also users), turned it off due to it annoying h

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/28/2007 11:00 PM, [EMAIL PROTECTED] wrote: many -mm users use it anyway? He himself said he's not convinced of usefulness having not seen it help for him (and notice that most developers are also users), turned it off due to it annoying him at some point and hasn't seen a serious investi

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/28/2007 01:21 PM, Alan Cox wrote: It is. Prefetched pages can be dropped on the floor without additional I/O. Which is essentially free for most cases. In addition your disk access may well have been in idle time (and should be for this sort of stuff) Yes. The swap-prefetch patch ensu

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Sat, 28 Jul 2007 21:33:59 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > > What I think is killing us here is the blockdev pagecache: the pagecache > > which backs those directory entries and inodes. These pages get read > > multiple times because they hold multiple

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

Andrew Morton wrote: What I think is killing us here is the blockdev pagecache: the pagecache which backs those directory entries and inodes. These pages get read multiple times because they hold multiple directory entries and multiple inodes. These multiple touches will put those pages onto t

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Saturday 28 July 2007 17:06:50 [EMAIL PROTECTED] wrote: > On Sat, 28 Jul 2007, Daniel Hazelton wrote: > > On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: > >> On Sat, 28 Jul 2007, Rene Herman wrote: > >>> On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: > On Fri, 27 Jul 2007, Re

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Sat, 28 Jul 2007, Daniel Hazelton wrote: On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: On Sat, 28 Jul 2007, Rene Herman wrote: On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007, Rene Herman wrote: On 07/27/2007 07:45 PM, Daniel Hazelton wrote: nobody i

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Sat, 28 Jul 2007, Alan Cox wrote: It is. Prefetched pages can be dropped on the floor without additional I/O. Which is essentially free for most cases. In addition your disk access may well have been in idle time (and should be for this sort of stuff) and if it was in the same chunk as some

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

nted these pages in the recent past, so it's a reasonable guess to say that the user will want them again in the future" Well, _that_ is what the kernel is already going to great lengths at doing, and it decided that those pages us poor overnight OO.o users want in in the morning weren&#

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/28/07, Alan Cox <[EMAIL PROTECTED]> wrote: > Actual physical disk ops are precious resource and anything that mostly > reduces the number will be a win - not to stay swap prefetch is the right > answer but accidentally or otherwise there are good reasons it may happen > to help. > > Bigger mor

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: > On Sat, 28 Jul 2007, Rene Herman wrote: > > On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: > >> On Fri, 27 Jul 2007, Rene Herman wrote: > >> > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > >> > > Questions about it: > >> > > Q)

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

> symptom, so it can't go in"? > > And once again, I personally have nothing against swap-prefetch, or > something like it. I can see how it or something like it could be made > to improve the lives of people who get up in the morning to find their > apps sitting on disk

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

> It is. Prefetched pages can be dropped on the floor without additional I/O. Which is essentially free for most cases. In addition your disk access may well have been in idle time (and should be for this sort of stuff) and if it was in the same chunk as something nearby was effectively free anywa

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

pages in the recent past, so it's a reasonable guess to say that the user will want them again in the future" Well, _that_ is what the kernel is already going to great lengths at doing, and it decided that those pages us poor overnight OO.o users want in in the morning weren't re

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Sat, 28 Jul 2007, Rene Herman wrote: On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007, Rene Herman wrote: > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > > > Questions about it: > > Q) Does swap-prefetch help with this? > > A) [From all reports I've seen (*

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/28/2007 09:35 AM, Rene Herman wrote: By the way -- I'm unable to make my slocate grow substantial here but I'll try what GNU locate does. If it's really as bad as I hear then regardless of anything else it should really be either fixed or dumped... Yes. GNU locate is broken and nobody s

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

lly have nothing against swap-prefetch, or something like it. I can see how it or something like it could be made to improve the lives of people who get up in the morning to find their apps sitting on disk due to memory pressure generated by over-night system maintenance operations. The aut

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/28/2007 01:15 AM, Björn Steinbrink wrote: On 2007.07.27 20:16:32 +0200, Rene Herman wrote: Here's swap-prefetch's author saying the same: http://lkml.org/lkml/2007/2/9/112 | It can't help the updatedb scenario. Updatedb leaves the ram full and | swap prefetch wants to cost as little a

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007, Rene Herman wrote: On 07/27/2007 07:45 PM, Daniel Hazelton wrote: Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. No it does not. If updatedb filled memory

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

memory pressure that causes other applications to be swapped to disk. In the morning the user has to wait for the system to swap those applications back in. I never said that it was the *program* itself - or *any* specific program (I used "Updatedb" because it has been the big name in the

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Friday 27 July 2007 19:29:19 Andi Kleen wrote: > > Any faults in that reasoning? > > GNU sort uses a merge sort with temporary files on disk. Not sure > how much it keeps in memory during that, but it's probably less > than 150MB. At some point the dirty limit should kick in and write back the >

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 2007.07.28 01:29:19 +0200, Andi Kleen wrote: > > Any faults in that reasoning? > > GNU sort uses a merge sort with temporary files on disk. Not sure > how much it keeps in memory during that, but it's probably less > than 150MB. At some point the dirty limit should kick in and write back the >

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

> Any faults in that reasoning? GNU sort uses a merge sort with temporary files on disk. Not sure how much it keeps in memory during that, but it's probably less than 150MB. At some point the dirty limit should kick in and write back the data of the temporary files; so it's not quite the same as

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

other applications to be swapped to disk. In the >> morning the user has to wait for the system to swap those applications >> back in. >> Questions about it: >> Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] >> Yes, it does. > >

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Friday 27 July 2007 18:08:44 Mike Galbraith wrote: > On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote: > > On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: > > > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: > > > > So hrm. Are we sure that updatedb is the problem? There

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote: > On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: > > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: > > > So hrm. Are we sure that updatedb is the problem? There are quite a few > > > heavyweight things which happen in the

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

er applications to be swapped to disk. In the > > morning the user has to wait for the system to swap those applications > > back in. > > > > Questions about it: > > Q) Does swap-prefetch help with this? > > A) [From all reports I've seen (*)] Yes, it does.

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

. In the morning the user has to wait for the system to swap those applications back in. Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. No it does not. If updatedb filled memory to the point of causing swapping (which noo

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

Al Viro wrote: > BTW, I really wonder how much pain could be avoided if updatedb recorded > mtime of directories and checked it. Someone mentioned a variant of slocate above that they called mlocate, and that Red Hat ships, that seems to do this (if I understand you and what mlocate does correctly

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 07/27/2007 07:45 PM, Daniel Hazelton wrote: Updatedb or another process that uses the FS heavily runs on a users 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory pressure that causes other applications to be swapped to disk. In the morning the user has to wait for the

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

nterprise users and ignoring the home users") So... The problem: Updatedb or another process that uses the FS heavily runs on a users 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory pressure that causes other applications to be swapped to disk. In the morning the user

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: > On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > More sophisticated testing is needed - there's something in > > ext3-tools which will mmap, page in and hold a file for you. > > So much for that theory. af

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > More sophisticated testing is needed - there's something in > ext3-tools which will mmap, page in and hold a file for you. So much for that theory. afaict mmapped, active pagecache is immune to updatedb activity. It j

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, 2007-07-27 at 01:47 -0700, Andrew Morton wrote: > Anyway, blockdev pagecache is a problem, I expect. It's worth playing with > that patch. (may tinker a bit, but i'm way rusty. ain't had the urge to mutilate anything down there in quite a while... works just fine for me these days) > A

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, 27 Jul 2007 09:54:41 +0100 Al Viro <[EMAIL PROTECTED]> wrote: > On Fri, Jul 27, 2007 at 01:47:49AM -0700, Andrew Morton wrote: > > What I think is killing us here is the blockdev pagecache: the pagecache > > which backs those directory entries and inodes. These pages get read > > multiple

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, Jul 27, 2007 at 01:47:49AM -0700, Andrew Morton wrote: > What I think is killing us here is the blockdev pagecache: the pagecache > which backs those directory entries and inodes. These pages get read > multiple times because they hold multiple directory entries and multiple > inodes. The

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, 27 Jul 2007 09:23:41 +0200 Mike Galbraith <[EMAIL PROTECTED]> wrote: > On Fri, 2007-07-27 at 07:13 +0200, Mike Galbraith wrote: > > On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote: > > > > drops caches prior to both updatedb runs. > > > > > > I think that was the wrong thing to do.

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Fri, 2007-07-27 at 07:13 +0200, Mike Galbraith wrote: > On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote: > > > drops caches prior to both updatedb runs. > > > > I think that was the wrong thing to do. That will leave gobs of free > > memory for updatedb to populate with dentries and ino

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Thu, 2007-07-26 at 11:05 -0700, Andrew Morton wrote: > On Thu, 26 Jul 2007 14:46:58 +0200 Mike Galbraith <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-07-26 at 03:09 -0700, Andrew Morton wrote: > > > > > Setting it to zero will maximise the preservation of the vfs caches. You > > > wanted 100

Re: [ck] Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On 7/26/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > wrong, it's active on three of my boxes already :) But then again, i > never had these hangover problems. (not really expected with gigs of RAM > anyway) [...] > --- /etc/cron.daily/mlocate.cron.orig [...] mlocate by design doesn't thrash the ca

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Thu, 26 Jul 2007 14:46:58 +0200 Mike Galbraith <[EMAIL PROTECTED]> wrote: > On Thu, 2007-07-26 at 03:09 -0700, Andrew Morton wrote: > > > Setting it to zero will maximise the preservation of the vfs caches. You > > wanted 1 there. > > > > > > drops caches prior to both updatedb runs.

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Thu, Jul 26, 2007 at 02:23:30PM +0200, Andi Kleen wrote: > That would just save reading the directories. Not sure > it helps that much. Much better would be actually if it didn't stat the > individual files (and force their dentries/inodes in). I bet it does that to > find out if they are dire

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Thu, 2007-07-26 at 03:09 -0700, Andrew Morton wrote: > Setting it to zero will maximise the preservation of the vfs caches. You > wanted 1 there. > > drops caches prior to both updatedb runs. [EMAIL PROTECTED]: df -i FilesystemInodes IUsed IFree IUse% Mounted on /dev/hd

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

> BTW, I really wonder how much pain could be avoided if updatedb recorded > mtime of directories and checked it. I.e. instead of just doing blind > find(1), walk the stored directory tree comparing timestamps with those > in filesystem. If directory mtime has not changed, don't bother rereading

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

On Thu, 26 Jul 2007 12:27:30 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > ( we _do_ want to baloon the dentry cache otherwise - for things like > > > > > "find" - having a fast VFS is important. But known-use-once things > > > > >

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

* Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > ( we _do_ want to baloon the dentry cache otherwise - for things like > > > > "find" - having a fast VFS is important. But known-use-once things > > > > like the daily updatedb job can clearly be annotated properly. ) > > > > > > Mutter.

Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

* Andrew Morton <[EMAIL PROTECTED]> wrote: > Setting it to zero will maximise the preservation of the vfs caches. > You wanted 1 there. ok, updated patch below :-) > wrong, it's active on three of my boxes already :) But then again, i never had these hangover problems. (not really expe

  1   2   >