LKML Archive on
help / color / mirror / Atom feed
From: William Lee Irwin III <>
To: Adam Litke <>
Cc: Andrew Morton <>,
	Arjan van de Ven <>,
	Christoph Hellwig <>,
	Ken Chen <>,,
Subject: Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2)
Date: Tue, 20 Mar 2007 18:17:57 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20070319200502.17168.17175.stgit@localhost.localdomain>

On Mon, Mar 19, 2007 at 01:05:02PM -0700, Adam Litke wrote:
> Andrew, given the favorable review of these patches the last time
> around, would you consider them for the -mm tree?  Does anyone else
> have any objections?

We need a new round of commentary for how it should integrate with
Nick Piggin's fault handling patches given that both introduce very
similar ->fault() methods, albeit at different places and for different

I think things weren't entirely wrapped up last time but there was
general approval in concept and code-level issues had been gotten past.
I've forgotten the conclusion of hch and arjan's commentary on making
the pagetable operations mandatory. ISTR they were all cosmetic affairs
like that or whether they should be part of ->vm_ops as opposed to
fundamental issues.

The last thing I'd want to do is hold things back, so by no means
delay merging etc. on account of this, but I am curious on several
points. First, is there any demonstrable overhead to mandatory indirect
calls for the pagetable operations? Second, can case analysis for e.g.
file-backed vs. anon and/or COW vs. shared be avoided by the use of
the indirect function call, or more specifically, to any beneficial
effect? Well, I rearranged the code in such a manner ca. 2.6.6 so I
know the rearrangement is possible, but not the performance impact vs.
modern kernels, if any, never mind how the code ends up looking in
modern kernels. Third, could you use lmbench or some such to get direct
fork() and fault handling microbenchmarks? Kernel compiles are too
close to macrobenchmarks to say anything concrete there apart from that
other issues (e.g. SMP load balancing, NUMA, lock contention, etc.)
dominate indirect calls. If you have the time or interest to explore
any of these areas, I'd be very interested in hearing the results.

One thing I would like to see for sure is dropping the has_pt_op()
and pt_op() macros. The Linux-native convention is to open-code the
function pointer fetches, and the non-native convention is to wrap
things like defaulting (though they actually do something more involved)
in the analogue of pt_op() for the purposes of things like extensible
sets of operations bordering on OOP-ish method tables. So this ends up
as some sort of hybrid convention without the functionality of the
non-native call wrappers and without the clarity of open-coding. My
personal preference is that the function pointer table be mandatory and
the call to the the function pointer be unconditional and the type
dispatch accomplished entirely through the function pointers, but I'm
not particularly insistent about that.

-- wli

  parent reply	other threads:[~2007-03-21  1:17 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-19 20:05 Adam Litke
2007-03-19 20:05 ` [PATCH 1/7] Introduce the pagetable_operations and associated helper macros Adam Litke
2007-03-20 23:24   ` Dave Hansen
2007-03-21 14:50     ` Adam Litke
2007-03-21 15:05       ` Arjan van de Ven
2007-03-21  4:18   ` Nick Piggin
2007-03-21  4:52     ` William Lee Irwin III
2007-03-21  5:07       ` Nick Piggin
2007-03-21  5:41         ` William Lee Irwin III
2007-03-21  6:51           ` Nick Piggin
2007-03-21  7:36             ` Nick Piggin
2007-03-21 10:46             ` William Lee Irwin III
2007-03-21 15:17     ` Adam Litke
2007-03-21 16:00       ` Christoph Hellwig
2007-03-21 23:03         ` Nick Piggin
2007-03-21 23:02       ` Nick Piggin
2007-03-21 23:32         ` William Lee Irwin III
2007-03-19 20:05 ` [PATCH 2/7] copy_vma for hugetlbfs Adam Litke
2007-03-19 20:05 ` [PATCH 3/7] pin_pages for hugetlb Adam Litke
2007-03-19 20:05 ` [PATCH 4/7] unmap_page_range " Adam Litke
2007-03-20 23:27   ` Dave Hansen
2007-03-19 20:05 ` [PATCH 5/7] change_protection " Adam Litke
2007-03-19 20:06 ` [PATCH 6/7] free_pgtable_range " Adam Litke
2007-03-19 20:06 ` [PATCH 7/7] hugetlbfs fault handler Adam Litke
2007-03-20 23:50 ` [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2) Dave Hansen
2007-03-21  1:17 ` William Lee Irwin III [this message]
2007-03-21 15:55 ` Hugh Dickins
2007-03-21 16:01   ` Christoph Hellwig
2007-03-21 19:43 ` pagetable_ops: Hugetlb character device example Adam Litke
2007-03-21 19:51   ` Valdis.Kletnieks
2007-03-21 20:26     ` Adam Litke
2007-03-21 22:26     ` William Lee Irwin III
2007-03-21 22:53       ` Matt Mackall
2007-03-21 23:35         ` William Lee Irwin III
2007-03-22  0:31           ` Matt Mackall
2007-03-22 10:38   ` Christoph Hellwig
2007-03-22 15:42     ` Mel Gorman
2007-03-22 18:15       ` Christoph Hellwig
2007-03-23 14:57         ` Mel Gorman

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API (V2)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).