linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm+eric@ccr.net (Eric W. Biederman)
To: Ingo Molnar <mingo@chiara.csoma.elte.hu>
Cc: Christoph Rohland <hans-christoph.rohland@sap.com>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	"Eric W. Biederman" <ebiederm+eric@ccr.net>,
	fxzhang@chpc.ict.ac.cn, "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Why don't we make mmap MAP_SHARED with /dev/zero possible?
Date: 03 Nov 1999 08:50:42 -0600	[thread overview]
Message-ID: <m1r9i7y6gt.fsf@flinx.hidden> (raw)
In-Reply-To: Ingo Molnar's message of "Wed, 3 Nov 1999 15:29:35 +0100 (CET)"

Ingo Molnar <mingo@chiara.csoma.elte.hu> writes:

> On 26 Oct 1999, Christoph Rohland wrote:
> 
> > This lines up with some remarks from Eric Biederman about his shmfs,
> > which is BTW a feature I would _love_ to have in Linux to do posix shm
> > and perhaps redo sysv shm. He said that he would like to make the
> > pagecache highmem-capable and AFAIK the main work for shmfs was
> > makeing the pagecache working with writeable pages.
> 
> hm, i've got the pagecache in high memory already on my box, patch under
> cleanup right now. It was the next natural step after doing all the hard
> work to get 64GB RAM support. Eric, is there any conflicting work here?

Not really.  I played with the idea, and the only really tricky aspect I saw
was how to write a version of copy_to/from_user that would handle the bigmem
case.   Because kmap ... copy .. kunmap  isn't safe as you can sleep due
to a page fault.

I got about half way to a solution by having the page fault handler basically
act like an exception handler, and switch the return address for this one specific
case.  So eventualy when the page fault would return area would magically
rekmap itself, and continue with life.  Duing it this was is important
as it only penalizes the uncommon case.  So within a clock or two
highmem_copy_to/from_user should be as fast as copy_to/from_user.

And I played with putting a wrapper around ll_rw_block calls in buffer.c
that would allocate bounce buffers from the buffer cache as needed.

I've been a little busy so keeping up with the kernel changes has been too much
just lately.  I wound up hacking on dosemu instead where I can out a six month
old patch and finish it up. . .

I'll probably get back to shmfs in a kernel version or two.
>From the last pre-2.3.25-3 it looks like everything I have proposed,
except moving bdflush to the page cache level is finding it's way into
the kernel.  And that last isn't critical for 2.4+

So when I get back to hacking it.  I'm going to concentrate on the
practical things needed to get shmfs working on 2.3.25+
And let some of the rest of you work on the generic mechanisms,
you are doing fine right now. . .

If you'd like to compare mechanisms or whatever I'd be happy too.

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

  reply	other threads:[~1999-11-03 14:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <qwwzox6l3nh.fsf@sap.com>
1999-11-03 14:29 ` Ingo Molnar
1999-11-03 14:50   ` Eric W. Biederman [this message]
1999-11-03 16:46     ` Ingo Molnar
1999-11-03 18:55       ` Eric W. Biederman
1999-11-03 19:16       ` Eric W. Biederman
1999-11-03 20:24         ` Ingo Molnar
1999-11-03 19:32           ` Benjamin C.R. LaHaise
1999-11-03 21:41             ` Ingo Molnar
1999-10-26  1:57 fxzhang
1999-10-26  7:35 ` Christoph Rohland
1999-10-26 12:05   ` Stephen C. Tweedie
1999-10-26 12:07 ` Stephen C. Tweedie

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=m1r9i7y6gt.fsf@flinx.hidden \
    --to=ebiederm+eric@ccr.net \
    --cc=fxzhang@chpc.ict.ac.cn \
    --cc=hans-christoph.rohland@sap.com \
    --cc=linux-mm@kvack.org \
    --cc=mingo@chiara.csoma.elte.hu \
    --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