public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Rico Tudor <rico@patrec.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [patch] highmem-2.4.2-A0
Date: Tue, 27 Feb 2001 00:41:11 +0100	[thread overview]
Message-ID: <20010227004111.A7143@athlon.random> (raw)
In-Reply-To: <20010226181049.G29254@athlon.random> <Pine.LNX.4.30.0102262139420.7414-200000@elte.hu>
In-Reply-To: <Pine.LNX.4.30.0102262139420.7414-200000@elte.hu>; from mingo@elte.hu on Mon, Feb 26, 2001 at 09:44:16PM +0100

On Mon, Feb 26, 2001 at 09:44:16PM +0100, Ingo Molnar wrote:
> -ac4. Differences: no need to complicate highmem.c with pool-fillup on
> bootup. It will get refilled after the first disk-accesses anyway.

I considered that, in practice it isn't going to make any difference, I
_totally_ agree. But to be also theorically correct we must refill it at boot
as well because we don't have the guarantee that the private pool isn't
necessary at the first I/O. As I just implemented it, I think it certainly
worth to keep it as the only penality will be a few more bytes in the bzImage.

> i'm unsure about the other changes done by your patch, could you explain
> them? Notably the pgalloc-3level.h and fault.c changes. Thanks,

I commented them in another parallel threads in l-k in the last days (I
included them into the code because I have stack traces with PAE that shows
weird things that at first looked closely related to the vmalloc race, but
quite frankly I still couldn't completly explain how the vmalloc race could
trigger such weird traces). Maybe it was the wakeup_bdflush(1) potential stack
overflow. I'm waiting feedback from the people who can reproduce.

Andrea

  reply	other threads:[~2001-02-26 23:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-26  1:21 64GB option broken in 2.4.2 Rico Tudor
2001-02-26  1:32 ` Alan Cox
2001-02-26  8:44   ` Rico Tudor
2001-02-26 11:14     ` Alan Cox
2001-02-26 17:10     ` Andrea Arcangeli
2001-02-26 20:44       ` [patch] highmem-2.4.2-A0 Ingo Molnar
2001-02-26 23:41         ` Andrea Arcangeli [this message]
2001-02-27  2:32       ` 64GB option broken in 2.4.2 Rico Tudor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010227004111.A7143@athlon.random \
    --to=andrea@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rico@patrec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox