From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Andrew Morton <akpm@digeo.com>
Cc: William Lee Irwin III <wli@holomorphy.com>, linux-mm@kvack.org
Subject: Re: get_user_pages rewrite rediffed against 2.5.47-mm1
Date: Mon, 18 Nov 2002 00:27:10 +0100 [thread overview]
Message-ID: <20021118002710.B659@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <3DD56256.C0911282@digeo.com>; from akpm@digeo.com on Fri, Nov 15, 2002 at 01:08:38PM -0800
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
Hi Andrew,
Hi William,
On Fri, Nov 15, 2002 at 01:08:38PM -0800, Andrew Morton wrote:
> Ingo Oeser wrote:
> >
> > ...
> > I envision the following usage:
> >
> > setup(&page_walk,...); /* currently done explicitly on stack */
> > walk_user_pages(&page_walk);
> Good. The callers shouldn't have to know how to initialise the
> state structure.
The problem is: Sometimes they know it and duplicate the work.
But I'll tackle that next time.
> I'd say just keep it to "pull the user pagetable access code out of
> memory.c". As much as you can, but not unrelated things. One
> concept per file would be nice.
Ok, so I created {mm/,include/linux/}page_walk.[ch]
> > All improvements in that direction have only been with block devices
> > in mind so far. I even don't see how I could improve the usage in
> > fs/dio.c, because it might sleep very long, so I can't use a page
> > walker for it (which needs the mmap_sem).
>
> Well I had plans there to reuse the page walker structure. So it
> would become a big stateful thing which you just feed into the
> walker engine and it spits out pages. With the callback page-processor
> being able to return information such as "OK, that's enough pages
> for now, let's start some IO".
The walk_user_pages is actually made for this.
Return values:
1 -> The walker was satisfied
0 -> No more pages there
Negative -> some error occured, and we cleaned already up.
So it should be quite simple to use and simplify all the error
handling, too.
The code got shorter by using a struct and stack usage looks smaller.
Most of the page walking users got simpler and also the
hugetlb code looks much better now.
The diffstat shows 554 deletions and 224 additions, which is not
too bad for a cleanup, which also adds a feature.
BTW: make_pages_present needs a rewrite, because it duplicates
work from its callers. The only non-trivial user is mm/mremap.c,
the rest of it I could do.
Comments are VERY welcome. bzip2ed patch attached.
Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
[-- Attachment #2: page-walk-api-2.5.47-mm3-cleanup.patch.bz2 --]
[-- Type: application/octet-stream, Size: 7890 bytes --]
next prev parent reply other threads:[~2002-11-17 23:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-12 19:58 Ingo Oeser
2002-11-12 20:27 ` Andrew Morton
2002-11-15 7:58 ` Ingo Oeser
2002-11-15 21:08 ` Andrew Morton
2002-11-17 23:27 ` Ingo Oeser [this message]
2002-11-18 1:12 ` William Lee Irwin III
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=20021118002710.B659@nightmaster.csn.tu-chemnitz.de \
--to=ingo.oeser@informatik.tu-chemnitz.de \
--cc=akpm@digeo.com \
--cc=linux-mm@kvack.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