On Sun, 8 Jul 2001, Rik van Riel wrote:
>
> If __wait_on_buffer and ___wait_on_page get stuck, this could
> mean a page doesn't get unlocked. When this is happening, we
> may well be running into a dozens of pages which aren't getting
> properly unlocked on IO completion.
Absolutely. But that,
On Sun, 8 Jul 2001, Linus Torvalds wrote:
> (a) _had_ the page been on any of the aging lists, it would have been
> aged down every time we passed it, and
> (b) it's obviously been aged up every time we passed it in the VM so far
> (because it hadn't been added to the swap cache earl
On Sun, 8 Jul 2001, Linus Torvalds wrote:
> On Sun, 8 Jul 2001, Rik van Riel wrote:
> >
> > ... Bingo. You hit the infamous __wait_on_buffer / ___wait_on_page
> > bug. I've seen this for quite a while now on our quad xeon test
> > machine, with some kernel versions it can be reproduced in minutes
On Sun, 8 Jul 2001, Rik van Riel wrote:
>
> ... Bingo. You hit the infamous __wait_on_buffer / ___wait_on_page
> bug. I've seen this for quite a while now on our quad xeon test
> machine, with some kernel versions it can be reproduced in minutes,
> with others it won't trigger at all.
Hmm.. Tha
On Sun, 8 Jul 2001, Rik van Riel wrote:
> On Sun, 8 Jul 2001, Mike Galbraith wrote:
>
> > is very oom with no disk activity. It _looks_ (xmm and vmstat) like
> > it just ran out of cleanable dirty pages. With or without swap,
>
> ... Bingo. You hit the infamous __wait_on_buffer / ___wait_on_pa
On Sat, 7 Jul 2001, Rik van Riel wrote:
>
> Not quite. The more a page has been used, the higher the
> page->age will be. This means the system has a way to
> distinguish between anonymous pages which were used once
> and anonymous pages which are used lots of times.
Wrong.
We already _have_ th
On Sun, 8 Jul 2001, Mike Galbraith wrote:
> is very oom with no disk activity. It _looks_ (xmm and vmstat) like
> it just ran out of cleanable dirty pages. With or without swap,
... Bingo. You hit the infamous __wait_on_buffer / ___wait_on_page
bug. I've seen this for quite a while now on our
On Sat, 7 Jul 2001, Alan Cox wrote:
> > > Its certainly misleading. I got Jeff to try making oom return
> > > 4999 out of 5000 times regardless.
> >
> > In that case, he _is_ OOM. ;)
>
> Hardly
>
> > 1) (almost) no free memory
> > 2) no free swap
> > 3) very little pagecache + buffer cache
>
> L
> > Its certainly misleading. I got Jeff to try making oom return
> > 4999 out of 5000 times regardless.
>
> In that case, he _is_ OOM. ;)
Hardly
> 1) (almost) no free memory
> 2) no free swap
> 3) very little pagecache + buffer cache
Large amounts of cache, which went away when the OOM code
Rik van Riel wrote:
>
> On Sat, 7 Jul 2001, Alan Cox wrote:
>
> > > instead. That way the vmstat output might be more useful, although vmstat
> > > obviously won't know about the new "SwapCache:" field..
> > >
> > > Can you try that, and see if something else stands out once the misleading
> > >
> But neutering the OOM killer like Alan suggested may be a rather valid
> approach anyway. Delaying the killing sounds valid: if we're truly
> livelocked on the VM, we'll be calling down to the OOM killer so much that
> it's probably quite valid to say "only return 1 after X iterations".
Its hid
On Sat, 7 Jul 2001, Alan Cox wrote:
> > instead. That way the vmstat output might be more useful, although vmstat
> > obviously won't know about the new "SwapCache:" field..
> >
> > Can you try that, and see if something else stands out once the misleading
> > accounting is taken care of?
>
> Its
> instead. That way the vmstat output might be more useful, although vmstat
> obviously won't know about the new "SwapCache:" field..
>
> Can you try that, and see if something else stands out once the misleading
> accounting is taken care of?
Its certainly misleading. I got Jeff to try making o
On Sat, 7 Jul 2001, Linus Torvalds wrote:
> In fact, I do not see any part of the whole path that sets the
> page age at all, so we're basically using a completely
> uninitialized field here (it's been initialized way back when
> the page was allocated, but because it hasn't been part of the
> no
On Sat, 7 Jul 2001, Rik van Riel wrote:
>
> Not at all. Note that try_to_swap_out() will happily
> create swap cache pages with a very high page->age,
> pages which are in absolutely no danger of being
> evicted from memory...
That seems to be a bug in "add_to_swap_cache()".
In fact, I do not s
On Sat, 7 Jul 2001, Jeff Garzik wrote:
> Sigh. since I am a VM ignoramus I doubt my opinion matters much
> at all here... but it would be nice if oddball configurations
> like 384MB with 50MB swap could be supported.
It would be fun if we had 48 hours in a day, too ;)
This particular thing has
Linus Torvalds wrote:
>
> On Sat, 7 Jul 2001, Jeff Garzik wrote:
> > Linus Torvalds wrote:
> > >
> > > Now, the fact that the system appears unusable does obviously mean that
> > > something is wrong. But you're barking up the wrong tree.
> >
> > Two more additional data points,
> >
> > 1) partia
On Sat, 7 Jul 2001, Jeff Garzik wrote:
> 2) I agree that 200MB into swap and 200MB into cache isn't bad
> per se, but when it triggers the OOM killer it is bad.
Please read my patch for the OOM killer. It substracts the
swap cache from the cache figure you quote and ONLY goes
into oom_kill() if
On Sat, 7 Jul 2001, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >
> > Now, the fact that the system appears unusable does obviously mean that
> > something is wrong. But you're barking up the wrong tree.
>
> Two more additional data points,
>
> 1) partially kernel-unrelated. MDK's "make" macro
Linus Torvalds wrote:
>
> On Sat, 7 Jul 2001, Jeff Garzik wrote:
> >
> > When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha,
> > the system goes --deeply-- into swap. Not pretty at all. The system
> > will be 200MB+ into swap, with 200MB+ in cache! I presume this affects
> >
On Sat, 7 Jul 2001, Jeff Garzik wrote:
>
> When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha,
> the system goes --deeply-- into swap. Not pretty at all. The system
> will be 200MB+ into swap, with 200MB+ in cache! I presume this affects
> 2.4.7-release also.
Note that "200
Jeff Garzik wrote:
>
> Oh this is a fun one :)
>
> When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha,
> the system goes --deeply-- into swap. Not pretty at all. The system
> will be 200MB+ into swap, with 200MB+ in cache! I presume this affects
> 2.4.7-release also.
>
> S
Oh this is a fun one :)
When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha,
the system goes --deeply-- into swap. Not pretty at all. The system
will be 200MB+ into swap, with 200MB+ in cache! I presume this affects
2.4.7-release also.
System has 256MB of swap, and 384MB of
23 matches
Mail list logo
