From: Christoph Hellwig <hch@infradead.org>
To: linux-ia64@vger.kernel.org
Subject: Re: pgd_free, pmd_free, and pte_free trapping memory.
Date: Tue, 16 Mar 2004 14:48:20 +0000 [thread overview]
Message-ID: <20040316144820.A559@infradead.org> (raw)
In-Reply-To: <20040316112424.GA20203@lnx-holt>
On Tue, Mar 16, 2004 at 05:24:24AM -0600, Robin Holt wrote:
> Looking through the code, we have identified the source of the problem.
> The fork is occuring on one cpu where the pgd, pmd, and pte allocations
> get pages of memory local to that cpu. The worker thread is then
> migrated to a different cpu where it exits. The pages are then placed
> on the cpu which is very distant from where the memory is located.
>
> I looked at the i386 code which appears to have been very similar to the
> ia64 at one point in time, but no longer. They appear to have completely
> eliminated the quicklists. Is this the right direction for ia64?
>
> Since, when the pgd, pmd, and pte are ready to be freed, they are
> zeroed out again, I understand the benefit to keeping the entry around
> to save the time for zeroing out the page again. Why not have a single
> quicklist where all three are placed. How would node locality best play
> into placing items on the lists? Should we have one quicklist on
> each cpu that a cpu returns node local pages and then a node quicklist
> where we place pages that are not node local using cmpxchg?
Tjis quicklist thing is a workaround for not having per-cpu pages in
Linux <= 2.4. Your patch is a workaround for a workaround and gets a little
ugly. I'd say just rip the quicklists out like x86 and benchmark it.
That's less code and thus less complexity which is always good. Now if
the pre-zeroing actually makes a difference we might have to keep small
pre-zeroed list around, but I doubt this is really good idea (or even
nessecary)
next prev parent reply other threads:[~2004-03-16 14:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-16 11:24 pgd_free, pmd_free, and pte_free trapping memory Robin Holt
2004-03-16 14:48 ` Christoph Hellwig [this message]
2004-03-16 15:24 ` Robin Holt
2004-03-16 15:34 ` Christoph Hellwig
2004-03-17 12:27 ` Robin Holt
2004-03-17 16:20 ` Jack Steiner
2004-03-17 16:53 ` Christoph Hellwig
2004-03-17 17:10 ` David Mosberger
2004-03-17 20:33 ` Jack Steiner
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=20040316144820.A559@infradead.org \
--to=hch@infradead.org \
--cc=linux-ia64@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.