On 11/26/2014 06:35 PM, Michal Hocko wrote:
> On Tue 25-11-14 16:00:06, Michal Hocko wrote:
>> On Tue 25-11-14 16:13:16, Konstantin Khlebnikov wrote:
>>> On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko wrote:
On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
> On Thu, Nov 20, 2014 at
On 11/26/2014 06:35 PM, Michal Hocko wrote:
On Tue 25-11-14 16:00:06, Michal Hocko wrote:
On Tue 25-11-14 16:13:16, Konstantin Khlebnikov wrote:
On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko mho...@suse.cz wrote:
On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
On Thu, Nov 20, 2014 at
On Tue 25-11-14 16:00:06, Michal Hocko wrote:
> On Tue 25-11-14 16:13:16, Konstantin Khlebnikov wrote:
> > On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko wrote:
> > > On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
> > >> On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov
> > >>
On Tue 25-11-14 16:00:06, Michal Hocko wrote:
On Tue 25-11-14 16:13:16, Konstantin Khlebnikov wrote:
On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko mho...@suse.cz wrote:
On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov
On Tue 25-11-14 16:13:16, Konstantin Khlebnikov wrote:
> On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko wrote:
> > On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
> >> On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov
> >> wrote:
> >> > On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel
On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko wrote:
> On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
>> On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov
>> wrote:
>> > On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel wrote:
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
> On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov
> wrote:
> > On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 11/20/2014 09:42 AM, Konstantin Khlebnikov
On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel r...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2014 09:42 AM, Konstantin
On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko mho...@suse.cz wrote:
On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel r...@redhat.com wrote:
-BEGIN PGP
On Tue 25-11-14 16:13:16, Konstantin Khlebnikov wrote:
On Tue, Nov 25, 2014 at 1:59 PM, Michal Hocko mho...@suse.cz wrote:
On Mon 24-11-14 11:09:40, Konstantin Khlebnikov wrote:
On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Thu, Nov 20, 2014 at 5:50
On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov wrote:
> On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
>>
>>> I'm thinking about limitation for reusing anon_vmas which
On Thu, Nov 20, 2014 at 6:03 PM, Konstantin Khlebnikov koc...@gmail.com wrote:
On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel r...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
I'm thinking about limitation for reusing
On Thu, Nov 20, 2014 at 3:42 PM, Konstantin Khlebnikov wrote:
> On Thu, Nov 20, 2014 at 2:14 AM, Michel Lespinasse wrote:
>> On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov
>> wrote:
>>> On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote:
Also from reading
On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
>
>> I'm thinking about limitation for reusing anon_vmas which might
>> increase performance without breaking asymptotic estimation of
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
> I'm thinking about limitation for reusing anon_vmas which might
> increase performance without breaking asymptotic estimation of
> count anon_vma in the worst case. For example this heuristic:
On Thu, Nov 20, 2014 at 2:14 AM, Michel Lespinasse wrote:
> On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov
> wrote:
>> On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote:
>>> Also from reading http://lwn.net/Articles/383162/ I understand that
>>> correctness
>>> also depends on
On Thu, Nov 20, 2014 at 2:14 AM, Michel Lespinasse wal...@google.com wrote:
On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka vba...@suse.cz wrote:
Also from reading http://lwn.net/Articles/383162/ I understand that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
I'm thinking about limitation for reusing anon_vmas which might
increase performance without breaking asymptotic estimation of
count anon_vma in the worst case. For example this heuristic: allow
On Thu, Nov 20, 2014 at 5:50 PM, Rik van Riel r...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2014 09:42 AM, Konstantin Khlebnikov wrote:
I'm thinking about limitation for reusing anon_vmas which might
increase performance without breaking asymptotic estimation
On Thu, Nov 20, 2014 at 3:42 PM, Konstantin Khlebnikov koc...@gmail.com wrote:
On Thu, Nov 20, 2014 at 2:14 AM, Michel Lespinasse wal...@google.com wrote:
On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka
On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov wrote:
> On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote:
>> Also from reading http://lwn.net/Articles/383162/ I understand that
>> correctness
>> also depends on the hierarchy and I wonder if there's a danger of
>> reintroducing
>>
On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka wrote:
> On 11/19/2014 03:36 PM, Konstantin Khlebnikov wrote:
>> On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka wrote:
>>> On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov
On 11/19/2014 03:36 PM, Konstantin Khlebnikov wrote:
> On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka wrote:
>> On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
>>> On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov
>>> wrote:
On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka wrote:
> On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
>> On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov
>> wrote:
>>> On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
>>> wrote:
On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel
On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka vba...@suse.cz wrote:
On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Mon,
On 11/19/2014 03:36 PM, Konstantin Khlebnikov wrote:
On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka vba...@suse.cz wrote:
On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Tue, Nov 18, 2014 at 11:19 PM,
On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka vba...@suse.cz wrote:
On 11/19/2014 03:36 PM, Konstantin Khlebnikov wrote:
On Wed, Nov 19, 2014 at 2:50 AM, Vlastimil Babka vba...@suse.cz wrote:
On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
On Wed, Nov 19, 2014 at 1:15 AM, Konstantin
On Wed, Nov 19, 2014 at 8:58 AM, Konstantin Khlebnikov koc...@gmail.com wrote:
On Wed, Nov 19, 2014 at 7:09 PM, Vlastimil Babka vba...@suse.cz wrote:
Also from reading http://lwn.net/Articles/383162/ I understand that
correctness
also depends on the hierarchy and I wonder if there's a danger
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 03:19 PM, Andrew Morton wrote:
> On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel
> wrote:
>
>> That way people can understand what the code does simply by
>> looking at the changelog - no need to go find old linux-kernel
>> mailing
On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
> On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov
> wrote:
>> On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
>> wrote:
>>> On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel wrote:
>>>
> Because of the serial forking there does
On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov wrote:
> On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
> wrote:
>> On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel wrote:
>>
>>> > Because of the serial forking there does indeed end up being an
>>> > infinite number of vmas. The initial
On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
wrote:
> On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel wrote:
>
>> > Because of the serial forking there does indeed end up being an
>> > infinite number of vmas. The initial vma can never be deleted
>> > (even though the initial parent process
On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel wrote:
> > Because of the serial forking there does indeed end up being an
> > infinite number of vmas. The initial vma can never be deleted
> > (even though the initial parent process has long since terminated)
> > because the initial vma is
On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel r...@redhat.com wrote:
Because of the serial forking there does indeed end up being an
infinite number of vmas. The initial vma can never be deleted
(even though the initial parent process has long since terminated)
because the initial vma
On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel r...@redhat.com wrote:
Because of the serial forking there does indeed end up being an
infinite number of vmas. The initial vma can never be deleted
(even
On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov koc...@gmail.com wrote:
On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel r...@redhat.com wrote:
Because of the serial forking there does indeed end up being
On 11/19/2014 12:02 AM, Konstantin Khlebnikov wrote:
On Wed, Nov 19, 2014 at 1:15 AM, Konstantin Khlebnikov koc...@gmail.com
wrote:
On Tue, Nov 18, 2014 at 11:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel r...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 03:19 PM, Andrew Morton wrote:
On Mon, 17 Nov 2014 21:41:57 -0500 Rik van Riel r...@redhat.com
wrote:
That way people can understand what the code does simply by
looking at the changelog - no need to go find old linux-kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2014 08:41 PM, Daniel Forrest wrote:
> On Mon, Nov 17, 2014 at 04:02:12PM -0800, Andrew Morton wrote:
>> On Fri, 14 Nov 2014 10:30:53 -0600 Daniel Forrest
>> wrote:
>>
>>> There have been a couple of inquiries about the status of this
>>>
On Mon, Nov 17, 2014 at 04:02:12PM -0800, Andrew Morton wrote:
> On Fri, 14 Nov 2014 10:30:53 -0600 Daniel Forrest
> wrote:
>
> > There have been a couple of inquiries about the status of this patch
> > over the last few months, so I am going to try pushing it out.
> >
> > Andrea Arcangeli has
On Fri, 14 Nov 2014 10:30:53 -0600 Daniel Forrest
wrote:
> There have been a couple of inquiries about the status of this patch
> over the last few months, so I am going to try pushing it out.
>
> Andrea Arcangeli has commented:
>
> > Agreed. The only thing I don't like about this patch is
On Fri, 14 Nov 2014 10:30:53 -0600 Daniel Forrest dan.forr...@ssec.wisc.edu
wrote:
There have been a couple of inquiries about the status of this patch
over the last few months, so I am going to try pushing it out.
Andrea Arcangeli has commented:
Agreed. The only thing I don't like
On Mon, Nov 17, 2014 at 04:02:12PM -0800, Andrew Morton wrote:
On Fri, 14 Nov 2014 10:30:53 -0600 Daniel Forrest dan.forr...@ssec.wisc.edu
wrote:
There have been a couple of inquiries about the status of this patch
over the last few months, so I am going to try pushing it out.
Andrea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2014 08:41 PM, Daniel Forrest wrote:
On Mon, Nov 17, 2014 at 04:02:12PM -0800, Andrew Morton wrote:
On Fri, 14 Nov 2014 10:30:53 -0600 Daniel Forrest
dan.forr...@ssec.wisc.edu wrote:
There have been a couple of inquiries about the
There have been a couple of inquiries about the status of this patch
over the last few months, so I am going to try pushing it out.
Andrea Arcangeli has commented:
> Agreed. The only thing I don't like about this patch is the hardcoding
> of number 5: could we make it a variable to tweak with
There have been a couple of inquiries about the status of this patch
over the last few months, so I am going to try pushing it out.
Andrea Arcangeli has commented:
Agreed. The only thing I don't like about this patch is the hardcoding
of number 5: could we make it a variable to tweak with
On Tue, Jun 04, 2013 at 06:37:25AM -0400, Rik van Riel wrote:
> On 06/03/2013 03:50 PM, Daniel Forrest wrote:
> > On Tue, Aug 21, 2012 at 11:29:54PM -0400, Rik van Riel wrote:
> >> On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
> >>> On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse
On Tue, Jun 04, 2013 at 06:37:25AM -0400, Rik van Riel wrote:
On 06/03/2013 03:50 PM, Daniel Forrest wrote:
On Tue, Aug 21, 2012 at 11:29:54PM -0400, Rik van Riel wrote:
On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
On 06/03/2013 03:50 PM, Daniel Forrest wrote:
On Tue, Aug 21, 2012 at 11:29:54PM -0400, Rik van Riel wrote:
On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
Instead of adding an atomic count for page references, we could limit
On 06/03/2013 03:50 PM, Daniel Forrest wrote:
On Tue, Aug 21, 2012 at 11:29:54PM -0400, Rik van Riel wrote:
On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
Instead of adding an atomic count for page references, we could limit
On Tue, Aug 21, 2012 at 11:29:54PM -0400, Rik van Riel wrote:
> On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
> >On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
> >>Instead of adding an atomic count for page references, we could limit
> >>the anon_vma stacking depth. In fork,
On Tue, Aug 21, 2012 at 11:29:54PM -0400, Rik van Riel wrote:
On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
Instead of adding an atomic count for page references, we could limit
the anon_vma stacking depth. In fork, we would
On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
Instead of adding an atomic count for page references, we could limit
the anon_vma stacking depth. In fork, we would only clone anon_vmas
that have a low enough generation count.
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
> Instead of adding an atomic count for page references, we could limit
> the anon_vma stacking depth. In fork, we would only clone anon_vmas
> that have a low enough generation count. I think that's not great
> (adds a special
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
Instead of adding an atomic count for page references, we could limit
the anon_vma stacking depth. In fork, we would only clone anon_vmas
that have a low enough generation count. I think that's not great
(adds a special case
On 08/21/2012 11:20 PM, Michel Lespinasse wrote:
On Mon, Aug 20, 2012 at 02:39:26AM -0700, Michel Lespinasse wrote:
Instead of adding an atomic count for page references, we could limit
the anon_vma stacking depth. In fork, we would only clone anon_vmas
that have a low enough generation count.
On Mon, Aug 20, 2012 at 4:53 AM, Michel Lespinasse wrote:
> I wonder if it might help to add the child VMA onto the parent's
> anon_vma only at the first child COW event. That way it would at least
> be possible (with userspace changes) for any forking servers to
> separate the areas they want to
On Mon, Aug 20, 2012 at 4:17 AM, Rik van Riel wrote:
> Without the anon_vma_chains, we end up scanning every single
> one of the child processes (and the parent) for every COWed
> page, which can be a real issue when the VM runs into 1000
> such pages, for 1000 child processes.
>
> Unfortunately,
On 08/20/2012 05:39 AM, Michel Lespinasse wrote:
I would still prefer if we could just remove the anon_vma_chain stuff, though.
If only we could.
That simply replaces a medium issue at fork time, with the
potential for a catastrophic issue at page reclaim time,
in any workload with heavily
Michel Lespinasse writes:
>
> I would still prefer if we could just remove the anon_vma_chain stuff, though.
Would probably help with the fork locking problems too.
We never really recovered from that regression.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe
On Mon, Aug 20, 2012 at 1:00 AM, Hugh Dickins wrote:
> On Fri, 17 Aug 2012, Rik van Riel wrote:
>> Of course, that leaves the big question: do we want the
>> overhead of having the atomic addition and decrement for
>> every anonymous memory page, or is it easier to fix this
>> issue in userspace?
On Fri, 17 Aug 2012, Rik van Riel wrote:
> On 08/17/2012 08:03 PM, Daniel Forrest wrote:
>
> > Based on your comments, I came up with the following patch. It boots
> > and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
> > if I've overlooked something. I'm not a kernel
On Fri, 17 Aug 2012, Rik van Riel wrote:
On 08/17/2012 08:03 PM, Daniel Forrest wrote:
Based on your comments, I came up with the following patch. It boots
and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
if I've overlooked something. I'm not a kernel hacker.
On Mon, Aug 20, 2012 at 1:00 AM, Hugh Dickins hu...@google.com wrote:
On Fri, 17 Aug 2012, Rik van Riel wrote:
Of course, that leaves the big question: do we want the
overhead of having the atomic addition and decrement for
every anonymous memory page, or is it easier to fix this
issue in
Michel Lespinasse wal...@google.com writes:
I would still prefer if we could just remove the anon_vma_chain stuff, though.
Would probably help with the fork locking problems too.
We never really recovered from that regression.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To
On 08/20/2012 05:39 AM, Michel Lespinasse wrote:
I would still prefer if we could just remove the anon_vma_chain stuff, though.
If only we could.
That simply replaces a medium issue at fork time, with the
potential for a catastrophic issue at page reclaim time,
in any workload with heavily
On Mon, Aug 20, 2012 at 4:17 AM, Rik van Riel r...@redhat.com wrote:
Without the anon_vma_chains, we end up scanning every single
one of the child processes (and the parent) for every COWed
page, which can be a real issue when the VM runs into 1000
such pages, for 1000 child processes.
On Mon, Aug 20, 2012 at 4:53 AM, Michel Lespinasse wal...@google.com wrote:
I wonder if it might help to add the child VMA onto the parent's
anon_vma only at the first child COW event. That way it would at least
be possible (with userspace changes) for any forking servers to
separate the areas
On 08/18/2012 12:07 AM, Daniel Forrest wrote:
I was being careful since I wasn't certain about the locking. Does
the test need to be protected by "lock_anon_vma_root"? That's why I
chose the overhead of the possible wasted "anon_vma_chain_alloc".
The function anon_vma_clone is being called
On Fri, Aug 17, 2012 at 11:46:18PM -0400, Rik van Riel wrote:
> On 08/17/2012 08:03 PM, Daniel Forrest wrote:
>
> >Based on your comments, I came up with the following patch. It boots
> >and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
> >if I've overlooked something. I'm
On 08/17/2012 08:03 PM, Daniel Forrest wrote:
Based on your comments, I came up with the following patch. It boots
and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
if I've overlooked something. I'm not a kernel hacker.
The patch looks reasonable to me. There is one
On Thu, Aug 16, 2012 at 02:58:45PM -0400, Rik van Riel wrote:
> Oh dear.
>
> Basically, what happens is that at fork time, a new
> "level" is created for the anon_vma hierarchy. This
> works great for normal forking daemons, since the
> parent process just keeps running, and forking off
>
On Thu, Aug 16, 2012 at 02:58:45PM -0400, Rik van Riel wrote:
Oh dear.
Basically, what happens is that at fork time, a new
level is created for the anon_vma hierarchy. This
works great for normal forking daemons, since the
parent process just keeps running, and forking off
children.
On 08/17/2012 08:03 PM, Daniel Forrest wrote:
Based on your comments, I came up with the following patch. It boots
and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
if I've overlooked something. I'm not a kernel hacker.
The patch looks reasonable to me. There is one
On Fri, Aug 17, 2012 at 11:46:18PM -0400, Rik van Riel wrote:
On 08/17/2012 08:03 PM, Daniel Forrest wrote:
Based on your comments, I came up with the following patch. It boots
and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
if I've overlooked something. I'm not a
On 08/18/2012 12:07 AM, Daniel Forrest wrote:
I was being careful since I wasn't certain about the locking. Does
the test need to be protected by lock_anon_vma_root? That's why I
chose the overhead of the possible wasted anon_vma_chain_alloc.
The function anon_vma_clone is being called from
On 08/15/2012 10:46 PM, Daniel Forrest wrote:
I'm hoping someone has seen this before...
I've been trying to track down a performance problem with Linux 3.0.4.
The symptom is system-mode load increasing over time while user-mode
load remains constant while running a data ingest/processing
On 08/15/2012 10:46 PM, Daniel Forrest wrote:
I'm hoping someone has seen this before...
I've been trying to track down a performance problem with Linux 3.0.4.
The symptom is system-mode load increasing over time while user-mode
load remains constant while running a data ingest/processing
I'm hoping someone has seen this before...
I've been trying to track down a performance problem with Linux 3.0.4.
The symptom is system-mode load increasing over time while user-mode
load remains constant while running a data ingest/processing program.
Looking at /proc/meminfo I noticed
I'm hoping someone has seen this before...
I've been trying to track down a performance problem with Linux 3.0.4.
The symptom is system-mode load increasing over time while user-mode
load remains constant while running a data ingest/processing program.
Looking at /proc/meminfo I noticed
80 matches
Mail list logo
