linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "David S. Miller" <davem@redhat.com>,
	linux-mm@kvack.org, "Stephen C. Tweedie" <sct@redhat.com>,
	Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: [RFC] 2-pointer PTE chaining idea
Date: Fri, 19 Jan 2001 21:22:23 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.10.10101192108150.2760-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.31.0101191849050.3368-100000@localhost.localdomain>


On Fri, 19 Jan 2001, Rik van Riel wrote:
> 
> > The only sane way I can think of to do the "implied pointer" is to do an
> > order-2 allocation when you allocate a page directory: you get 16kB of
> 
> How about doing an order-1 allocation and having a singly linked
> list ?

The thing is, that _whatever_ you do, I think it's going to suck.

I'll tell you why: I think you're trying to optimize the uncommon case. 

I realize that you think that page table scanning is slow etc. I happen to
think it's acceptable, but never mind that. More important is the fact
that NOT scanning the page tables is what is the normal case BY FAR.

Do you actually have any profiles showing that scanning the page tables is
a problem? I realize that you can create loads that scan the page tables a
lot, but have you really understood and internalized the fact that those
same loads thend to have a CPU usage of just a few percent? The bad loads
tend to spend more time waiting for IO to complete because everybody is
busy SWAPPING.

And you have to realize, that it doesn't MATTER if we spend even 25% of
the CPU power on scanning the page tables (and I want to point out that
I've never heard of such a load), if we spend 50% idle just waiting for
the disk (and the rest of the time mayb eworking or in other VM routines).

This is why I don't think this "try to be clever to avoid work when
swapping" approach is really all that relevant.

There are two IMPORTANT things to do in the VM layer:

 - select the right pages. Don't worry too much about CPU at this point:
   if you have to do IO it's ok to waste some cycles per page. You'll win
   bigger from selecting the right page, than from trying to make the
   infrastructure really cheap.

 - DO NOT WASTE TIME IF YOU HAVE MEMORY!

Th esecond point is important. You have to really think about how Linux
handles anonymous pages, and understand that that is not just an accident.
It's really important to NOT do extra work for the case where an
application just wants a page. Don't allocate swap backing store early.
Don't add it to the page cache if it doesn't need to be there. Don't do
ANYTHING.

This, btw, also implies: don't make the page tables more complex.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2001-01-20  5:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-19  5:08 Rik van Riel
2001-01-19  6:57 ` David S. Miller
2001-01-19  7:17   ` Linus Torvalds
2001-01-19  7:55     ` Rik van Riel
2001-01-20  5:22       ` Linus Torvalds [this message]
2001-01-20  5:31         ` David S. Miller
2001-01-20  7:05           ` Rik van Riel
2001-01-19 11:49     ` Ingo Molnar
2001-01-20  6:58     ` Rik van Riel
2001-01-19 11:37 ` Ingo Molnar

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=Pine.LNX.4.10.10101192108150.2760-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=davem@redhat.com \
    --cc=dillon@apollo.backplane.com \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.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