On Fri, 13 Apr 2001 01:02:21 +0200, Szabolcs Szakacsits said:
> Not __alloc_pages() calls oom_kill() however do_page_fault(). Not the
> same. After the system tried *really* hard to get *one* free page and
> couldn't managed why loop forever? To eat CPU and waiting for
For what it's worth, this
On Thu, 12 Apr 2001, Rik van Riel wrote:
> On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
> > You mean without dropping out_of_memory() test in kswapd and calling
> > oom_kill() in page fault [i.e. without additional patch]?
> No. I think it's ok for __alloc_pages() to call oom_kill()
> IF we
On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
> You mean without dropping out_of_memory() test in kswapd and calling
> oom_kill() in page fault [i.e. without additional patch]?
No. I think it's ok for __alloc_pages() to call oom_kill()
IF we turn out to be out of memory, but that should not
On Thu, 12 Apr 2001, Rik van Riel wrote:
> On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
> > I still feel a bit unconfortable about processes looping forever in
> > __alloc_pages and because of this oom_killer also can't be moved to
> > page fault handler where I think its place should be. I'm
On Thu, 12 Apr 2001 16:12:55 BST, Alan Cox said:
> Do you have > 800Mb of RAM ?
Following up - it just bit again (twice)
The first time, it was xmms/kswapd fighting for CPU, and xmms was again immune
to kill -9. Interestingly enough, several minutes later, I closed 'netscape',
and xmms took
On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
> On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
>
> > This patch is broken, ignore it.
> > Just removing wakeup_bdflush() is indeed correct.
> > We already wakeup bdflush at try_to_free_buffers() anyway.
>
> I still feel a bit unconfortable about
On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
> This patch is broken, ignore it.
> Just removing wakeup_bdflush() is indeed correct.
> We already wakeup bdflush at try_to_free_buffers() anyway.
I still feel a bit unconfortable about processes looping forever in
__alloc_pages and because of this
On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
> This should fix it
>
> --- mm/page_alloc.c.orig Thu Apr 12 13:47:53 2001
> +++ mm/page_alloc.cThu Apr 12 13:48:06 2001
> @@ -454,7 +454,7 @@
> if (gfp_mask & __GFP_WAIT) {
> memory_pressure++;
>
On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
>
> I did :)
>
> This should fix it
>
> --- mm/page_alloc.c.orig Thu Apr 12 13:47:53 2001
> +++ mm/page_alloc.cThu Apr 12 13:48:06 2001
> @@ -454,7 +454,7 @@
> if (gfp_mask & __GFP_WAIT) {
>
On Thu, 12 Apr 2001, Rik van Riel wrote:
> On Thu, 12 Apr 2001, Alan Cox wrote:
>
> > > 2.4.3-pre6 quietly made a very significant change there:
> > > it used to say "if (!order) goto try_again;" and now just
> > > says "goto try_again;". Which seems very sensible since
> > > __GFP_WAIT is
On Thu, 12 Apr 2001, Alan Cox wrote:
> > 2.4.3-pre6 quietly made a very significant change there:
> > it used to say "if (!order) goto try_again;" and now just
> > says "goto try_again;". Which seems very sensible since
> > __GFP_WAIT is set, but I do wonder if it was a safe change.
> > We have
> 2.4.3-pre6 quietly made a very significant change there:
> it used to say "if (!order) goto try_again;" and now just
> says "goto try_again;". Which seems very sensible since
> __GFP_WAIT is set, but I do wonder if it was a safe change.
> We have mechanisms for freeing pages (order 0), but
On Wed, Apr 11 2001, Josh McKinney wrote:
> I had the almost exact same thing happen to me just yesterday, I started up
> xcdroast, and cdda2wav and kswapd went crazy, backed out of X and all was
> well, and still is.
>
> Same kernel as you too.
I can tell you why this happens. Earlier kernels
On Thu, 12 Apr 2001 16:12:55 BST, Alan Cox said:
> > I've seen the same scenario about 2-3 times a week. kswapd and one or
> > more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
> > on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
> > The 'hung'
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote:
> I've seen the same scenario about 2-3 times a week. kswapd and one or
> more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
> on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
> The 'hung' processes are
> I've seen the same scenario about 2-3 times a week. kswapd and one or
> more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
> on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
> The 'hung' processes are consistently immune to kill -9, even as root,
I've seen the same scenario about 2-3 times a week. kswapd and one or
more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
The 'hung' processes are consistently immune to kill -9, even as root, which
I've seen the same scenario about 2-3 times a week. kswapd and one or
more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
The 'hung' processes are consistently immune to kill -9, even as root, which
I've seen the same scenario about 2-3 times a week. kswapd and one or
more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
The 'hung' processes are consistently immune to kill -9, even as root, which
On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote:
I've seen the same scenario about 2-3 times a week. kswapd and one or
more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
The 'hung' processes are
On Thu, 12 Apr 2001 16:12:55 BST, Alan Cox said:
I've seen the same scenario about 2-3 times a week. kswapd and one or
more processes all CPU bound, totalling to 100%. I've had 'esdplay' hung
on several occasions, and 2-3 times it's been xscreensaver (3.29) hung.
The 'hung' processes
On Wed, Apr 11 2001, Josh McKinney wrote:
I had the almost exact same thing happen to me just yesterday, I started up
xcdroast, and cdda2wav and kswapd went crazy, backed out of X and all was
well, and still is.
Same kernel as you too.
I can tell you why this happens. Earlier kernels
2.4.3-pre6 quietly made a very significant change there:
it used to say "if (!order) goto try_again;" and now just
says "goto try_again;". Which seems very sensible since
__GFP_WAIT is set, but I do wonder if it was a safe change.
We have mechanisms for freeing pages (order 0), but whether
On Thu, 12 Apr 2001, Alan Cox wrote:
2.4.3-pre6 quietly made a very significant change there:
it used to say "if (!order) goto try_again;" and now just
says "goto try_again;". Which seems very sensible since
__GFP_WAIT is set, but I do wonder if it was a safe change.
We have
On Thu, 12 Apr 2001, Rik van Riel wrote:
On Thu, 12 Apr 2001, Alan Cox wrote:
2.4.3-pre6 quietly made a very significant change there:
it used to say "if (!order) goto try_again;" and now just
says "goto try_again;". Which seems very sensible since
__GFP_WAIT is set, but I do
On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
This should fix it
--- mm/page_alloc.c.orig Thu Apr 12 13:47:53 2001
+++ mm/page_alloc.cThu Apr 12 13:48:06 2001
@@ -454,7 +454,7 @@
if (gfp_mask __GFP_WAIT) {
memory_pressure++;
On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
This patch is broken, ignore it.
Just removing wakeup_bdflush() is indeed correct.
We already wakeup bdflush at try_to_free_buffers() anyway.
I still feel a bit unconfortable about processes looping forever in
__alloc_pages and because of this
On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
This patch is broken, ignore it.
Just removing wakeup_bdflush() is indeed correct.
We already wakeup bdflush at try_to_free_buffers() anyway.
I still feel a bit unconfortable about processes
On Thu, 12 Apr 2001 16:12:55 BST, Alan Cox said:
Do you have 800Mb of RAM ?
Following up - it just bit again (twice)
The first time, it was xmms/kswapd fighting for CPU, and xmms was again immune
to kill -9. Interestingly enough, several minutes later, I closed 'netscape',
and xmms took the
On Thu, 12 Apr 2001, Rik van Riel wrote:
On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
I still feel a bit unconfortable about processes looping forever in
__alloc_pages and because of this oom_killer also can't be moved to
page fault handler where I think its place should be. I'm using
On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
You mean without dropping out_of_memory() test in kswapd and calling
oom_kill() in page fault [i.e. without additional patch]?
No. I think it's ok for __alloc_pages() to call oom_kill()
IF we turn out to be out of memory, but that should not
On Thu, 12 Apr 2001, Rik van Riel wrote:
On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
You mean without dropping out_of_memory() test in kswapd and calling
oom_kill() in page fault [i.e. without additional patch]?
No. I think it's ok for __alloc_pages() to call oom_kill()
IF we turn
On Fri, 13 Apr 2001 01:02:21 +0200, Szabolcs Szakacsits said:
Not __alloc_pages() calls oom_kill() however do_page_fault(). Not the
same. After the system tried *really* hard to get *one* free page and
couldn't managed why loop forever? To eat CPU and waiting for
For what it's worth, this
I had the almost exact same thing happen to me just yesterday, I started up
xcdroast, and cdda2wav and kswapd went crazy, backed out of X and all was
well, and still is.
Same kernel as you too.
On approximately Wed, Apr 11, 2001 at 04:24:48PM +0200, Priit Randla wrote:
>
>
> Hi,
>
>
>
I had the almost exact same thing happen to me just yesterday, I started up
xcdroast, and cdda2wav and kswapd went crazy, backed out of X and all was
well, and still is.
Same kernel as you too.
On approximately Wed, Apr 11, 2001 at 04:24:48PM +0200, Priit Randla wrote:
Hi,
35 matches
Mail list logo
