On (07/08/08 10:29), Dave Hansen didst pronounce:
> On Thu, 2008-08-07 at 17:06 +0100, Mel Gorman wrote:
> > On (06/08/08 12:50), Dave Hansen didst pronounce:
> > > The main thing this set of patches does that I care about is take an
> > > anonymous VMA and replace it with a hugetlb VMA. It does t
On Thu, 2008-08-07 at 17:06 +0100, Mel Gorman wrote:
> On (06/08/08 12:50), Dave Hansen didst pronounce:
> > The main thing this set of patches does that I care about is take an
> > anonymous VMA and replace it with a hugetlb VMA. It does this on a
> > special cue, but does it nonetheless.
>
> Th
On (06/08/08 12:50), Dave Hansen didst pronounce:
> On Wed, 2008-08-06 at 10:02 +0100, Mel Gorman wrote:
> > > That said, this particular patch doesn't appear *too* bound to hugetlb
> > > itself. But, some of its limitations *do* come from the filesystem,
> > > like its inability to handle VM_GROW
On Wed, 2008-08-06 at 10:02 +0100, Mel Gorman wrote:
> > That said, this particular patch doesn't appear *too* bound to hugetlb
> > itself. But, some of its limitations *do* come from the filesystem,
> > like its inability to handle VM_GROWS...
>
> The lack of VM_GROWSX is an issue, but on its
Andrew Morton <[EMAIL PROTECTED]> writes:
> Do we expect that this change will be replicated in other
> memory-intensive apps? (I do).
The catch with 2MB pages on x86 is that x86 CPUs generally have
much less 2MB TLB entries than 4K entries. So if you're unlucky
and access a lot of mappings you
On (05/08/08 10:53), Dave Hansen didst pronounce:
> On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote:
> > Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it
> > suits this patch. However, I don't see what you gain. By reusing hugetlbfs,
> > we get things like proper reserva
On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote:
> Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it
> suits this patch. However, I don't see what you gain. By reusing hugetlbfs,
> we get things like proper reservations which we can do for MAP_PRIVATE these
> days. Again,
On (05/08/08 09:12), Dave Hansen didst pronounce:
> On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
> > See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
> > To get that right between children, you end up something very fs-like
> > when the child needs to fault in a page
On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
> See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
> To get that right between children, you end up something very fs-like
> when the child needs to fault in a page that is already populated by the
> parent. I strongly sus
On (04/08/08 14:10), Dave Hansen didst pronounce:
> On Thu, 2008-07-31 at 11:31 +0100, Mel Gorman wrote:
> > We are a lot more reliable than we were although exact quantification is
> > difficult because it's workload dependent. For a long time, I've been able
> > to test bits and pieces with hugep
On Thu, 2008-07-31 at 11:31 +0100, Mel Gorman wrote:
> We are a lot more reliable than we were although exact quantification is
> difficult because it's workload dependent. For a long time, I've been able
> to test bits and pieces with hugepages by allocating the pool at the time
> I needed it even
On Thu, 2008-07-31 at 14:50 +0100, Mel Gorman wrote:
> On (31/07/08 21:51), Nick Piggin didst pronounce:
> > On Thursday 31 July 2008 21:27, Mel Gorman wrote:
> > > On (31/07/08 16:26), Nick Piggin didst pronounce:
> >
> > > > I imagine it should be, unless you're using a CPU with seperate TLBs fo
On (31/07/08 21:51), Nick Piggin didst pronounce:
> On Thursday 31 July 2008 21:27, Mel Gorman wrote:
> > On (31/07/08 16:26), Nick Piggin didst pronounce:
>
> > > I imagine it should be, unless you're using a CPU with seperate TLBs for
> > > small and huge pages, and your large data set is mapped
On Thursday 31 July 2008 21:27, Mel Gorman wrote:
> On (31/07/08 16:26), Nick Piggin didst pronounce:
> > I imagine it should be, unless you're using a CPU with seperate TLBs for
> > small and huge pages, and your large data set is mapped with huge pages,
> > in which case you might now introduce
On (31/07/08 16:26), Nick Piggin didst pronounce:
> On Thursday 31 July 2008 16:14, Andrew Morton wrote:
> > On Thu, 31 Jul 2008 16:04:14 +1000 Nick Piggin <[EMAIL PROTECTED]>
> wrote:
> > > > Do we expect that this change will be replicated in other
> > > > memory-intensive apps? (I do).
> > >
>
On (30/07/08 13:07), Andrew Morton didst pronounce:
> On Wed, 30 Jul 2008 20:30:10 +0100
> Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > With Erics patch and libhugetlbfs, we can automatically back text/data[1],
> > malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs
> > will
On Thursday 31 July 2008 16:14, Andrew Morton wrote:
> On Thu, 31 Jul 2008 16:04:14 +1000 Nick Piggin <[EMAIL PROTECTED]>
wrote:
> > > Do we expect that this change will be replicated in other
> > > memory-intensive apps? (I do).
> >
> > Such as what? It would be nice to see some numbers with som
On Thu, 31 Jul 2008 16:04:14 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Do we expect that this change will be replicated in other
> > memory-intensive apps? (I do).
>
> Such as what? It would be nice to see some numbers with some HPC or java
> or DBMS workload using this. Not that I disput
On Thursday 31 July 2008 03:34, Andrew Morton wrote:
> On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman <[EMAIL PROTECTED]> wrote:
> > On (30/07/08 01:43), Andrew Morton didst pronounce:
> > > On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <[EMAIL PROTECTED]>
wrote:
> > > > Certain workloads benefit
Mel Gorman wrote:
> With Erics patch and libhugetlbfs, we can automatically back text/data[1],
> malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs
> will also be able to override shmget() to add SHM_HUGETLB. That should cover
> a lot of the memory-intensive apps without s
On Wed, 30 Jul 2008 20:30:10 +0100
Mel Gorman <[EMAIL PROTECTED]> wrote:
> With Erics patch and libhugetlbfs, we can automatically back text/data[1],
> malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs
> will also be able to override shmget() to add SHM_HUGETLB. That shou
On (30/07/08 10:34), Andrew Morton didst pronounce:
> On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > On (30/07/08 01:43), Andrew Morton didst pronounce:
> > > On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <[EMAIL PROTECTED]> wrote:
> > >
> > > > Certain workloads
On (30/07/08 01:43), Andrew Morton didst pronounce:
> On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <[EMAIL PROTECTED]> wrote:
>
> > Certain workloads benefit if their data or text segments are backed by
> > huge pages.
>
> oh. As this is a performance patch, it would be much better if its
> de
On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman <[EMAIL PROTECTED]> wrote:
> On (30/07/08 01:43), Andrew Morton didst pronounce:
> > On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <[EMAIL PROTECTED]> wrote:
> >
> > > Certain workloads benefit if their data or text segments are backed by
> > > huge
/***
* User front end for using huge pages Copyright (C) 2008, IBM *
* *
* This program is free software; you can redistribute it and/or m
On Wed, 30 Jul 2008, Andrew Morton wrote:
> On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <[EMAIL PROTECTED]> wrote:
>
> > Certain workloads benefit if their data or text segments are backed by
> > huge pages. The stack is no exception to this rule but there is no
> > mechanism currently that al
On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <[EMAIL PROTECTED]> wrote:
> Certain workloads benefit if their data or text segments are backed by
> huge pages.
oh. As this is a performance patch, it would be much better if its
description contained some performance measurement results! Please.
On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <[EMAIL PROTECTED]> wrote:
> Certain workloads benefit if their data or text segments are backed by
> huge pages. The stack is no exception to this rule but there is no
> mechanism currently that allows the backing of a stack reliably with
> huge page
On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
>
> This patch stack introduces a personality flag that indicates the
> kernel
> should setup the stack as a hugetlbfs-backed region. A userspace
> utility
> may set this flag then exec a process whose stack is to be backed by
> hugetlb pages.
On Mon, 28 Jul 2008, Dave Hansen wrote:
> On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
> >
> > This patch stack introduces a personality flag that indicates the
> > kernel
> > should setup the stack as a hugetlbfs-backed region. A userspace
> > utility
> > may set this flag then exec a p
Certain workloads benefit if their data or text segments are backed by
huge pages. The stack is no exception to this rule but there is no
mechanism currently that allows the backing of a stack reliably with
huge pages. Doing this from userspace is excessively messy and has some
awkward restriction
31 matches
Mail list logo
