linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gerrit Huizenga <gh@us.ibm.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andrew Morton <akpm@zip.com.au>,
	"Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
	Hubertus Franke <frankeh@watson.ibm.com>,
	wli@holomorpy.com, swj@cse.unsw.edu.au,
	linux-mm mailing list <linux-mm@kvack.org>
Subject: Re: large page patch (fwd) (fwd)
Date: Fri, 02 Aug 2002 21:26:37 -0700	[thread overview]
Message-ID: <E17aqUv-000344-00@w-gerrit2> (raw)
In-Reply-To: Your message of Fri, 02 Aug 2002 18:26:29 PDT. <Pine.LNX.4.44.0208021757490.2210-100000@home.transmeta.com>

In message <Pine.LNX.4.44.0208021757490.2210-100000@home.transmeta.com>, > : Li
nus Torvalds writes:
> 
> 
> On Fri, 2 Aug 2002, Andrew Morton wrote:
> >
> > Remind me again what's wrong with wrapping the Intel syscalls
> > inside malloc() and then maybe grafting a little hook into the shm code?
> 
> Indeed.
 
Do you really want all calls to malloc to allocate non-pageable
memory?  And I doubt that this memory will be pageable in time for
2.5.

> However, don't think "Intel syscalls", think instead "bring out the
> architecture-defined mapping features". In particular, the main objection
> I had to Ingo's patch (which, by the sound of it is fairly similar to the
> IBM patches which I haven't seen) was that it was much too Intel-centric.
 
The IBM patch (Simon Winwood's work) was first done for PPC64 and then
ported at my insistence to IA32 since we had an immediate need and
an opportunity to do some specific application porting work on IA32.
The patch was intended to be both architecture neutral and to support
multiple page sizes.  In the essense of hitting the Halloween deadline,
we believe that dropping back for the moment to IA32, pinned, mmap()/
madvise()/shm*() versions, possibly gated by a capability (or not, easily
debatable and I doubt that it matters too much) will get at least IBM
apps on IA32 through the lifetime on 2.6 and probably have the framework
in such that PPC64 can also easily fit in possibly pre-freeze, possibly
post-freeze with mostly arch-specific mods.

> I admit to being x86-centric when it comes to implementation (simply due
> to the fact that they are cheap and everywhere), but I try very hard to
> avoid making _design_ revolve around x86. In particular, while I'm not a
> big fan of the PPC hash tables (understatement of the year), I _do_ like
> the BAT mapping that PPC has.

We folks in the LTC have much the same interest.  In addition to the
obvious IA32/PPC32/PPC64/zSeries/IA64/AMD issues (keep in mind we probably
sell more servers with PPC than with IA32 ;-), we have software products
which run on nearly every platform and every distro in existence.  So,
we too try to qualify most of our work on its potential application to
multiple architectures.

> (Alternatively, if you aren't familiar with BAT registers, think
> software-filled extra TLB entries that are outside the normal fill policy
> and have large sizes. For some architectures it makes sense to do this at
> sw TLB fill time, for others that isn't very practical because the page
> table lookup is fixed in various ways.)
 
>From what I've heard from the Watson Research experts on PPC64, BAT
registers are actually a bad idea for this and AIX is slowly removing
its dependency on BAT registers.  I'd be interested in a read from
Anton or Paul Mackerras or even the Research folks involved in the
chip design.

And, we are doing everything possible to at least provide code to
demonstrate the solutions we are talking about.  It just may take
a few days to get it properly accelerated.  ;-)

gerrit
--
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-mm.org/

  reply	other threads:[~2002-08-03  4:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.33.0208021252090.2466-100000@penguin.transmeta.com>
2002-08-02 23:54 ` Martin J. Bligh
2002-08-03  0:35   ` Andrew Morton
2002-08-03  1:26     ` Linus Torvalds
2002-08-03  4:26       ` Gerrit Huizenga [this message]
2002-08-03  4:39         ` 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=E17aqUv-000344-00@w-gerrit2 \
    --to=gh@us.ibm.com \
    --cc=Martin.Bligh@us.ibm.com \
    --cc=akpm@zip.com.au \
    --cc=frankeh@watson.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=swj@cse.unsw.edu.au \
    --cc=torvalds@transmeta.com \
    --cc=wli@holomorpy.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