From: Andrew Morton <akpm@digeo.com>
To: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Huge TLB pages always physically continious?
Date: Fri, 01 Nov 2002 15:23:02 -0800 [thread overview]
Message-ID: <3DC30CD6.D92D0F9F@digeo.com> (raw)
In-Reply-To: 20021101235620.A5263@nightmaster.csn.tu-chemnitz.de
Ingo Oeser wrote:
>
> Hi there,
>
> are huge TLB pages always physically continous in memory?
Yes.
> What does follow_hugetlb_page do exactly? I simply don't
> understand what the code does.
It allows get_user_pages() to work correctly across hugepage
regions. It walks a chunk of memory which is covered by
hugepages and installs (at *pages) the list of 4k-pages which
are covered by the hugepage. So
|--------------------------------------------------| <- hugepage
|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--| <- 4k pages
get_user_pages( ^here ^to here)
will install the spanned 4k pages into the caller's pages[]
array.
> I would like to build up a simplified get_user_pages_sgl() to
> build a scatter gather list from user space adresses.
>
> If I want to coalesce physically continous pages (if they are
> also virtually continious) anyway, can I write up a simplified
> follow_hugetlb_page_sgl() function which handles the huge page
> really as only one page?
I suggest that you restructure get_user_pages thusly:
1: Write a simplified get_user_page(). Most callers of get_user_pages()
only want a single page anyway, and don't need to concoct all those
arguments.
2: Split get_user_pages up into a pagetable walker and a callback function.
So it walks the pages, calling back to the caller's callback function
for each page with
(*callback)(struct page *page, <other stuff>, void *callerdata);
You'll need to extend follow_hugetlb_page() to take the callback
info and to perform the callbacks for its pages as well.
3: Reimplement the current get_user_pages() using the core engine from 2
(ie: write the callback for it)
4: Implement your sg engine using the walker+callback arrangement. This
way, you can do your coalescing on-the-fly, and you only take one
pass across the pages list and you do not need to know about hugepages
at all. Sure you'll do a *little* more work than you need to, but
not having that special case is nicer.
5: Fix up the ia64 follow_hugetlb_page too.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@digeo.com>
To: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Huge TLB pages always physically continious?
Date: Fri, 01 Nov 2002 15:23:02 -0800 [thread overview]
Message-ID: <3DC30CD6.D92D0F9F@digeo.com> (raw)
In-Reply-To: 20021101235620.A5263@nightmaster.csn.tu-chemnitz.de
Ingo Oeser wrote:
>
> Hi there,
>
> are huge TLB pages always physically continous in memory?
Yes.
> What does follow_hugetlb_page do exactly? I simply don't
> understand what the code does.
It allows get_user_pages() to work correctly across hugepage
regions. It walks a chunk of memory which is covered by
hugepages and installs (at *pages) the list of 4k-pages which
are covered by the hugepage. So
|--------------------------------------------------| <- hugepage
|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--| <- 4k pages
get_user_pages( ^here ^to here)
will install the spanned 4k pages into the caller's pages[]
array.
> I would like to build up a simplified get_user_pages_sgl() to
> build a scatter gather list from user space adresses.
>
> If I want to coalesce physically continous pages (if they are
> also virtually continious) anyway, can I write up a simplified
> follow_hugetlb_page_sgl() function which handles the huge page
> really as only one page?
I suggest that you restructure get_user_pages thusly:
1: Write a simplified get_user_page(). Most callers of get_user_pages()
only want a single page anyway, and don't need to concoct all those
arguments.
2: Split get_user_pages up into a pagetable walker and a callback function.
So it walks the pages, calling back to the caller's callback function
for each page with
(*callback)(struct page *page, <other stuff>, void *callerdata);
You'll need to extend follow_hugetlb_page() to take the callback
info and to perform the callbacks for its pages as well.
3: Reimplement the current get_user_pages() using the core engine from 2
(ie: write the callback for it)
4: Implement your sg engine using the walker+callback arrangement. This
way, you can do your coalescing on-the-fly, and you only take one
pass across the pages list and you do not need to know about hugepages
at all. Sure you'll do a *little* more work than you need to, but
not having that special case is nicer.
5: Fix up the ia64 follow_hugetlb_page too.
--
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/
next prev parent reply other threads:[~2002-11-01 23:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-01 22:56 Huge TLB pages always physically continious? Ingo Oeser
2002-11-01 23:23 ` Andrew Morton [this message]
2002-11-01 23:23 ` Andrew Morton
2002-11-02 8:29 ` Jeff Garzik
2002-11-02 8:29 ` Jeff Garzik
2002-11-04 13:49 ` get_user_pages rewrite (was: Huge TLB pages always physically continious?) Ingo Oeser
2002-11-04 13:49 ` Ingo Oeser
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=3DC30CD6.D92D0F9F@digeo.com \
--to=akpm@digeo.com \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.