public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: William Lee Irwin III <wli@holomorphy.com>,
	Linus Torvalds <torvalds@osdl.org>,
	mfedyk@matchmail.com, "Eric W. Biederman" <ebiederm@xmission.com>,
	Anton Ertl <anton@mips.complang.tuwien.ac.at>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	phillips@arcor.de
Subject: Re: Page Colouring (was: 2.6.0 Huge pages not working as expected)
Date: Mon, 29 Dec 2003 13:09:30 +0100	[thread overview]
Message-ID: <20031229120930.GA31941@elte.hu> (raw)
In-Reply-To: <20031229084304.GA31630@elte.hu>


* William Lee Irwin III <wli@holomorphy.com> wrote:

> I also heard something about this from daniel. The description I was
> given implied rather different functionality, and raised rather
> serious questions about the implementation he didn't have adequate
> answers for. I also never saw code, despite months of occasional
> discussions about it.
> 
> I did get a positive reaction from you at KS, and I've also been
> slaving away at keeping this thing current and improving it when I can
> for a year. Would you mind telling me what the Hell is going on here?
> 
> I guess I already know I'm screwed beyond all hope of recovery, but I
> might as well get official confirmation.

i've been following your code (pgcl) and it looks pretty good. (it needs
finishing touches as always, but that's fine.) I tried to backport it to
2.4 before doing 4G/4G but the maintainance overhead skyrocketed and so
it not practical for 2.4-based distribution purposes - but it would be
the perfect kind of thing to start 2.7.0 with. I've not seen any other
code but yours in this area.

i believe the right approach to the 'tons of RAM' problem is to simplify
it as much as possible, ie. go for larger pages (and wrap the MMU format
in the most trivial way) and to deal with 4K pages as a filesystem (and
ELF format) compatibility thing only. Your patch does precisely this.
How much we'll have to 'mix' the two page sizes, only practice will
tell, but the less mixing, the easier it will get. Filesystems on such
systems will match the pagesize anyway.

i'd even suggest to not overdo the fractured-page logic too much - ie.
just 'waste' a full page on a misaligned or single 4K-sized vma -
concentrate on the common case: linearly mapped files and anonymous
mappings. Prefault both of them at PAGE_SIZE granularity and 'waste' the
final partial page. The VM swapout logic should only deal with full
pages. Same for the pagecache: just fill in full pages and dont worry
about granularity.

Your patch already does more than this. But i think if someone does 4K
vmas on a pgcl system or runs it on a 128 MB box and expects perfect
swapping, then it's his damn fault.

	Ingo

  parent reply	other threads:[~2003-12-29 12:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <179fV-1iK-23@gated-at.bofh.it>
     [not found] ` <179IS-1VD-13@gated-at.bofh.it>
2003-12-27 20:21   ` Page Colouring (was: 2.6.0 Huge pages not working as expected) Anton Ertl
2003-12-27 20:56     ` Linus Torvalds
2003-12-27 23:31       ` Eric W. Biederman
2003-12-27 23:50         ` William Lee Irwin III
2003-12-28  1:09         ` David S. Miller
2003-12-28  4:53         ` Linus Torvalds
2003-12-28 16:39           ` William Lee Irwin III
2003-12-29  0:36             ` Mike Fedyk
2003-12-29  2:55               ` William Lee Irwin III
2003-12-29  4:09                 ` Linus Torvalds
2003-12-29  6:52                   ` William Lee Irwin III
2003-12-29  9:14                     ` Linus Torvalds
2003-12-29  9:22                       ` William Lee Irwin III
2003-12-29  9:33                         ` Linus Torvalds
2003-12-29 10:23                           ` William Lee Irwin III
2003-12-29 10:59                             ` Mike Fedyk
2003-12-29 11:14                               ` William Lee Irwin III
2003-12-30  2:00                             ` Rusty Russell
2003-12-30  4:59                               ` William Lee Irwin III
     [not found]                     ` <20031229084304.GA31630@elte.hu>
2003-12-29 12:09                       ` Ingo Molnar [this message]
2003-12-29 12:49                         ` William Lee Irwin III
2003-12-29 20:02                   ` Subpages (was: Page Colouring) Daniel Phillips
2003-12-29 20:15                     ` Linus Torvalds
2003-12-29 21:11           ` Page Colouring (was: 2.6.0 Huge pages not working as expected) Eric W. Biederman
2003-12-29 21:35             ` Linus Torvalds
     [not found]       ` <17tHK-3K6-21@gated-at.bofh.it>
2003-12-28 17:17         ` Anton Ertl
     [not found] <176UD-6vl-3@gated-at.bofh.it>
2003-12-26 21:48 ` Anton Ertl
2003-12-26 23:28   ` Linus Torvalds

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=20031229120930.GA31941@elte.hu \
    --to=mingo@elte.hu \
    --cc=anton@mips.complang.tuwien.ac.at \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=phillips@arcor.de \
    --cc=torvalds@osdl.org \
    --cc=wli@holomorphy.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