On Thu, Jul 14, 2005 at 07:00:11PM -0700, Christoph Lameter wrote:
> On Fri, 15 Jul 2005, David Gibson wrote:
>
> > Well, the COW patch implements a fault handler, obviously. What
> > specifically where you thinking about?
>
> About a fault handler of course and about surrounding scalability iss
On Fri, 15 Jul 2005, David Gibson wrote:
> I'm still not at all sure what you're getting at. Do you mean the
> demand-allocation patches which were floating around at some point - I
> gather they're important for doing sensible NUMA allocation of
> hugepages. They have a small overlap with the C
On Fri, 15 Jul 2005, David Gibson wrote:
> Well, the COW patch implements a fault handler, obviously. What
> specifically where you thinking about?
About a fault handler of course and about surrounding scalability issues.
I worked on some hugepage related patches last fall. Have you had a look
On Thu, Jul 14, 2005 at 10:24:33AM -0700, Christoph Lameter wrote:
> On Thu, 7 Jul 2005, David Gibson wrote:
>
> > Now that the hugepage code has been consolidated across the
> > architectures, it becomes much easier to implement copy-on-write.
> > Hugepage COW is of limited utility of itself, how
On Thu, 7 Jul 2005, David Gibson wrote:
> Now that the hugepage code has been consolidated across the
> architectures, it becomes much easier to implement copy-on-write.
> Hugepage COW is of limited utility of itself, however, it is
> essentially a prerequisite for any of a number of methods of al
On Thu, Jul 07, 2005 at 10:53:25PM +1000, Stephen Rothwell wrote:
> On Thu, 7 Jul 2005 19:24:25 +1000 David Gibson <[EMAIL PROTECTED]> wrote:
> >
> > That's not necessarily possible. On some archs - ppc64 for one -
> > the mmu has to be set up for hugepages on a granularity greater than
> > the hu
On Thu, 7 Jul 2005 19:24:25 +1000 David Gibson <[EMAIL PROTECTED]> wrote:
>
> That's not necessarily possible. On some archs - ppc64 for one -
> the mmu has to be set up for hugepages on a granularity greater than
> the hugepage size. So you can just arbitrarily substitute normal
On Thu, Jul 07, 2005 at 09:49:27AM +0300, Avi Kivity wrote:
> On Thu, 2005-07-07 at 15:55 +1000, David Gibson wrote:
>
> > MAP_PRIVATE|MAP_WRITE mappings of hugetlbfs. Because the pool of
> > hugepages is limited, a write to a MAP_PRIVATE hugepage region may
> > result in a SIGBUS, if a new huge
On Thu, 2005-07-07 at 15:55 +1000, David Gibson wrote:
> MAP_PRIVATE|MAP_WRITE mappings of hugetlbfs. Because the pool of
> hugepages is limited, a write to a MAP_PRIVATE hugepage region may
> result in a SIGBUS, if a new hugepage cannot be allocated. This patch
in that case you might allocate
Now that the hugepage code has been consolidated across the
architectures, it becomes much easier to implement copy-on-write.
Hugepage COW is of limited utility of itself, however, it is
essentially a prerequisite for any of a number of methods of allowing
userland programs to automatically use hug
10 matches
Mail list logo