xes this bug and also propagates the error
return value from anon_vma_clone() in all cases.
I can send this as a separate patch, but maybe it would be easier if
you were to incorporate it into yours?
Signed-off-by: Daniel Forrest
---
mmap.c | 10 +++---
rmap.c |6 --
2 files ch
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.
> >
he child
if it is more than five forks after the anon_vma was created, as we
don't want the same_vma chain to grow arbitrarily large.
Signed-off-by: Michel Lespinasse
Tested-by: Daniel Forrest
---
mm/mmap.c |6 +++---
mm/rmap.c | 18 ++
2 files changed, 17 ins
, but
> still better than the atomic page reference counter.
Here is an attached patch to demonstrate the idea.
anon_vma_clone() is modified to return the length of the existing same_vma
anon vma chain, and we create a new anon_vma in the child only on the first
fork (this could be twea
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&
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
> childre
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 SUnreclai
I am having a problem with memory allocation in a program when run
under Linux 2.6.18.
The program is statically linked and uses its own malloc library based
on brk(). Under previous versions of Linux it was able to allocate up
to ~3GB of memory before failing, now it fails at ~1GB.
The problem
On Fri, Jun 15, 2007 at 02:19:23PM +0100, Alan Cox wrote:
>
> > GPL itself does not. But the author(s) may when they specify "any
> > later version", "dual GPL/BSD", etc. In this case (IMHO) distributor
> > in fact relicenses the code and may reduce license to sipmply BSD or
> > simply GPL, or "GP
On Thu, Jun 14, 2007 at 02:52:48AM +0100, Alan Cox wrote:
>
> As a PS to the GPL3 comment here is the basic difference
>
> ROM - I can't modify the code on the device
> The creator can't modify the code further on the device
>
> Tivo - I can't modify the code on the
Hopefully someone can give me a quick answer...
Yesterday I discovered some processes that had a PPID which was not
shown as a running process by "ps". Also an "ls /proc" did not show
that PPID.
I've Googled on this enough to find out that these are Linux threads,
that "ps -m" will show them, th
11 matches
Mail list logo
