On Mon, Aug 15, 2005 at 12:37:50PM -0400, Bill Jordan wrote:
> On 8/11/05, Gleb Natapov <[EMAIL PROTECTED]> wrote:
> > What about the idea that was floating around about new VM flag that will
> > instruct kernel to copy pages belonging to the vma on fork instead of mark
> > them as cow?
> >
>
>
On Mon, Aug 15, 2005 at 12:37:50PM -0400, Bill Jordan wrote:
On 8/11/05, Gleb Natapov [EMAIL PROTECTED] wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages belonging to the vma on fork instead of mark
them as cow?
I think the
On 8/11/05, Gleb Natapov <[EMAIL PROTECTED]> wrote:
> What about the idea that was floating around about new VM flag that will
> instruct kernel to copy pages belonging to the vma on fork instead of mark
> them as cow?
>
I think the big problem with this idea is the huge memory regions that
On 8/11/05, Gleb Natapov [EMAIL PROTECTED] wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages belonging to the vma on fork instead of mark
them as cow?
I think the big problem with this idea is the huge memory regions that
InfiniBand
On Thu, 11 Aug 2005, Gleb Natapov wrote:
> On Thu, Aug 11, 2005 at 03:04:29PM +0100, Hugh Dickins wrote:
> > On Thu, 11 Aug 2005, Gleb Natapov wrote:
> > > What about the idea that was floating around about new VM flag that will
> > > instruct kernel to copy pages belonging to the vma on fork
On Thu, Aug 11, 2005 at 03:04:29PM +0100, Hugh Dickins wrote:
> On Thu, 11 Aug 2005, Gleb Natapov wrote:
> > What about the idea that was floating around about new VM flag that will
> > instruct kernel to copy pages belonging to the vma on fork instead of mark
> > them as cow?
>
> It's a pretty
Quoting r. Hugh Dickins <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: [PATCH repost] PROT_DONTCOPY: ifiniband
> uverbs fork support
>
> On Thu, 11 Aug 2005, Gleb Natapov wrote:
> > What about the idea that was floating around about new VM flag that will
>
On Thu, 11 Aug 2005, Gleb Natapov wrote:
> What about the idea that was floating around about new VM flag that will
> instruct kernel to copy pages belonging to the vma on fork instead of mark
> them as cow?
It's a pretty good idea, and thanks for reminding us of it.
It suffers from the general
On Wed, Aug 10, 2005 at 04:27:31PM +0100, Hugh Dickins wrote:
> On Wed, 10 Aug 2005, Gleb Natapov wrote:
> > On Wed, Aug 10, 2005 at 02:22:40PM +0100, Hugh Dickins wrote:
> > >
> > > Your stack example is a good one: if we end up setting VM_DONTCOPY on
> > > the user stack, then I don't think
On Wed, Aug 10, 2005 at 04:27:31PM +0100, Hugh Dickins wrote:
On Wed, 10 Aug 2005, Gleb Natapov wrote:
On Wed, Aug 10, 2005 at 02:22:40PM +0100, Hugh Dickins wrote:
Your stack example is a good one: if we end up setting VM_DONTCOPY on
the user stack, then I don't think fork's child
On Thu, 11 Aug 2005, Gleb Natapov wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages belonging to the vma on fork instead of mark
them as cow?
It's a pretty good idea, and thanks for reminding us of it.
It suffers from the general
On Thu, Aug 11, 2005 at 03:04:29PM +0100, Hugh Dickins wrote:
On Thu, 11 Aug 2005, Gleb Natapov wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages belonging to the vma on fork instead of mark
them as cow?
It's a pretty good idea,
Quoting r. Hugh Dickins [EMAIL PROTECTED]:
Subject: Re: [openib-general] Re: [PATCH repost] PROT_DONTCOPY: ifiniband
uverbs fork support
On Thu, 11 Aug 2005, Gleb Natapov wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages
On Thu, 11 Aug 2005, Gleb Natapov wrote:
On Thu, Aug 11, 2005 at 03:04:29PM +0100, Hugh Dickins wrote:
On Thu, 11 Aug 2005, Gleb Natapov wrote:
What about the idea that was floating around about new VM flag that will
instruct kernel to copy pages belonging to the vma on fork instead of
On Wed, 10 Aug 2005, Gleb Natapov wrote:
> On Wed, Aug 10, 2005 at 02:22:40PM +0100, Hugh Dickins wrote:
> >
> > Your stack example is a good one: if we end up setting VM_DONTCOPY on
> > the user stack, then I don't think fork's child will get very far without
> > hitting a SIGSEGV.
>
> I know,
On Wed, Aug 10, 2005 at 02:22:40PM +0100, Hugh Dickins wrote:
> On Wed, 10 Aug 2005, Gleb Natapov wrote:
> > On Tue, Aug 09, 2005 at 07:13:33PM +0100, Hugh Dickins wrote:
> > > Even more I'd prefer one of these two solutions below, which sidestep
> > > that uncleanliness - but both of these would
On Wed, 10 Aug 2005, Gleb Natapov wrote:
> On Tue, Aug 09, 2005 at 07:13:33PM +0100, Hugh Dickins wrote:
> > Even more I'd prefer one of these two solutions below, which sidestep
> > that uncleanliness - but both of these would be in mmap only, no clean
> > way to change afterwards (except by
On Tue, Aug 09, 2005 at 07:13:33PM +0100, Hugh Dickins wrote:
> Even more I'd prefer one of these two solutions below, which sidestep
> that uncleanliness - but both of these would be in mmap only, no clean
> way to change afterwards (except by munmap or mmap MAP_FIXED):
>
> 1. Use the standard
On Tue, Aug 09, 2005 at 07:13:33PM +0100, Hugh Dickins wrote:
Even more I'd prefer one of these two solutions below, which sidestep
that uncleanliness - but both of these would be in mmap only, no clean
way to change afterwards (except by munmap or mmap MAP_FIXED):
1. Use the standard
On Wed, 10 Aug 2005, Gleb Natapov wrote:
On Tue, Aug 09, 2005 at 07:13:33PM +0100, Hugh Dickins wrote:
Even more I'd prefer one of these two solutions below, which sidestep
that uncleanliness - but both of these would be in mmap only, no clean
way to change afterwards (except by munmap or
On Wed, Aug 10, 2005 at 02:22:40PM +0100, Hugh Dickins wrote:
On Wed, 10 Aug 2005, Gleb Natapov wrote:
On Tue, Aug 09, 2005 at 07:13:33PM +0100, Hugh Dickins wrote:
Even more I'd prefer one of these two solutions below, which sidestep
that uncleanliness - but both of these would be in
On Wed, 10 Aug 2005, Gleb Natapov wrote:
On Wed, Aug 10, 2005 at 02:22:40PM +0100, Hugh Dickins wrote:
Your stack example is a good one: if we end up setting VM_DONTCOPY on
the user stack, then I don't think fork's child will get very far without
hitting a SIGSEGV.
I know, but I
22 matches
Mail list logo
