All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Adam Litke <agl@us.ibm.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API
Date: Wed, 21 Feb 2007 06:57:40 +1100	[thread overview]
Message-ID: <1172001460.18571.134.camel@localhost.localdomain> (raw)
In-Reply-To: <1171919736.3531.98.camel@laptopd505.fenrus.org>


> maybe. I'm not entirely convinced... (I like the cleanup potential a lot
> code wise.. but if it costs performance, then... well I'd hate to see
> linux get slower for hugetlbfs)
> 
> > If not, then I definitely wouldn't
> > mind creating a default_pagetable_ops and calling into that.
> 
> ... but without it to be honest, your patch adds nothing real.. there's
> ONE user of your code, and there's no real cleanup unless you get rid of
> all the special casing.... since the special casing is the really ugly
> part of hugetlbfs, not the actual code inside the special case..

Well... I disagree there too :-)

I've been working recently for example on some spufs improvements that
require similar tweaking of the user address space as hugetlbfs. The
problem I have is that while there are hooks in the generic code pretty
much everywhere I need.... they are all hugetlb specific, that is they
call directly into the hugetlb code.

For now, I found ways of doing my stuff without hooking all over the
page table operations (well, I had no real choices) but I can imagine it
making sense to allow something (hugetlb being one of them) to take over
part of the user address space.

Ben.




WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Adam Litke <agl@us.ibm.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] [RFC] hugetlb: pagetable_operations API
Date: Wed, 21 Feb 2007 06:57:40 +1100	[thread overview]
Message-ID: <1172001460.18571.134.camel@localhost.localdomain> (raw)
In-Reply-To: <1171919736.3531.98.camel@laptopd505.fenrus.org>

> maybe. I'm not entirely convinced... (I like the cleanup potential a lot
> code wise.. but if it costs performance, then... well I'd hate to see
> linux get slower for hugetlbfs)
> 
> > If not, then I definitely wouldn't
> > mind creating a default_pagetable_ops and calling into that.
> 
> ... but without it to be honest, your patch adds nothing real.. there's
> ONE user of your code, and there's no real cleanup unless you get rid of
> all the special casing.... since the special casing is the really ugly
> part of hugetlbfs, not the actual code inside the special case..

Well... I disagree there too :-)

I've been working recently for example on some spufs improvements that
require similar tweaking of the user address space as hugetlbfs. The
problem I have is that while there are hooks in the generic code pretty
much everywhere I need.... they are all hugetlb specific, that is they
call directly into the hugetlb code.

For now, I found ways of doing my stuff without hooking all over the
page table operations (well, I had no real choices) but I can imagine it
making sense to allow something (hugetlb being one of them) to take over
part of the user address space.

Ben.



--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-02-20 20:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-19 18:31 [PATCH 0/7] [RFC] hugetlb: pagetable_operations API Adam Litke
2007-02-19 18:31 ` Adam Litke
2007-02-19 18:31 ` [PATCH 1/7] Introduce the pagetable_operations and associated helper macros Adam Litke
2007-02-19 18:31   ` Adam Litke
2007-02-19 18:41   ` Arjan van de Ven
2007-02-19 18:41     ` Arjan van de Ven
2007-02-19 19:31     ` Adam Litke
2007-02-19 19:31       ` Adam Litke
2007-02-19 19:48   ` William Lee Irwin III
2007-02-19 19:48     ` William Lee Irwin III
2007-02-19 22:29   ` Christoph Hellwig
2007-02-19 22:29     ` Christoph Hellwig
2007-02-20 15:50     ` Mel Gorman
2007-02-20 15:50       ` Mel Gorman
2007-02-19 18:31 ` [PATCH 2/7] copy_vma for hugetlbfs Adam Litke
2007-02-19 18:31   ` Adam Litke
2007-02-19 18:31 ` [PATCH 3/7] pin_pages for hugetlb Adam Litke
2007-02-19 18:31   ` Adam Litke
2007-02-19 18:32 ` [PATCH 4/7] unmap_page_range " Adam Litke
2007-02-19 18:32   ` Adam Litke
2007-02-19 18:32 ` [PATCH 5/7] change_protection " Adam Litke
2007-02-19 18:32   ` Adam Litke
2007-02-19 18:32 ` [PATCH 6/7] free_pgtable_range " Adam Litke
2007-02-19 18:32   ` Adam Litke
2007-02-19 18:32 ` [PATCH 7/7] hugetlbfs fault handler Adam Litke
2007-02-19 18:32   ` Adam Litke
2007-02-19 18:43 ` [PATCH 0/7] [RFC] hugetlb: pagetable_operations API Arjan van de Ven
2007-02-19 18:43   ` Arjan van de Ven
2007-02-19 19:34   ` Adam Litke
2007-02-19 19:34     ` Adam Litke
2007-02-19 21:15     ` Arjan van de Ven
2007-02-19 21:15       ` Arjan van de Ven
2007-02-20 19:57       ` Benjamin Herrenschmidt [this message]
2007-02-20 19:57         ` Benjamin Herrenschmidt
2007-02-20 19:54   ` Benjamin Herrenschmidt
2007-02-20 19:54     ` Benjamin Herrenschmidt

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=1172001460.18571.134.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=agl@us.ibm.com \
    --cc=arjan@infradead.org \
    --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.