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
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
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,
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
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
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, however,
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 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 COW
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 issues.
I
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
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
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
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
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 hugepage
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 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 hugepage
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
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
20 matches
Mail list logo
