Re: vfork: out of memory, when there's plenty of swap free

Andrea Arcangeli (andrea@e-mind.com)
Wed, 17 Mar 1999 00:54:56 +0100 (CET)


On Tue, 16 Mar 1999, Gerard Roudier wrote:

>You think that I shouldn't wrote kernel code, since you just wrote that in

I _never_ said that you shound't write kernel code. I said you that you
shouldn't write kernel code _if_ you _don't_ want to look around the .c
file you are working on. Everything can change over the time and what
_was_ safe could be not safe anymore now.

My point was that the kernel is so complex and there are so many possible
races that to make sure that your code is safe it's not always enough to
know only the specs about the kernel API you are using in your code. Just
to produce an example look at the write_lock_irq()/read_lock() race Ingo
discovered some week ago. Such race is not documented in spinlocks.txt (or
at least _was_ not documented), but _now_ you must know that to write SMP
safe code you can't cli() and then write_lock_irq() if other parts of the
kernel that may run on the other CPU uses read_lock() with irqs locally
enabled (otherwise the first cpu will loop waiting for the read_lock to be
released, and the second CPU will wait for the global_cli to be released).
And really, my original sentence was _only_ for making some good humor. I
am afraid if you misunderstood my point.

When I reply to emails I am quite relaxed and sometimes I tell what I
would tell you if you would be in front of me, but if you would be in
front of me you would notice a smile on my face (I tried adding it in my
sentence) and you would understood without mistake that was _only_ a joke.

>So, I am not going to post anything to these list for a while after this
>one. I will stay in my field, I mean scsi lists.

Really you are doing a mistake thinking I suggested you to not write
kernel code. As first I would be simply ridiculous telling you something
like that. And as second I will never suggest somebody to not write kernel
code. I only think (and was the reason for my sentence) is that writing
kernel code may need a larger understanding of the envinronment. If you
instead write GUI code for example you don't need to understand how X
works (as far as you use a sane toolkit ;). I think instead that writing
kernel code may need some more understanding of the global system to make
sure that the code is safe. But I can be wrong on this too because I never
gone into very large and complex GUI applications like netscape for
example, and again: my sentence was only a joke, really. So please excuse
me for beeing so clumsy in making humor in English.

>1 - process creation is not so critical for performances for having to pay
> for such a large area of memory allocated statically.

?? Your complain was about not failing the allocation.

>2 - I donnot want to reboot my system in order to be able to create more
> processes than a limit that is to be kept not to high because of
> its memory wasting approach.

You have just to do that (at least if you don't apply Ingo's large-task or
whatever is its name) patch.

Note, I perfectly know that my idea of the static stacks is not something
that has to go in, but I think it's a fast, clean and obviously-right
workaround of the task allocation problem you complained about. I think
that if you have an high end machine that is harmed by failed task
allocation due VM fragmentation (unlikely to happen according to me) you
may like more to not fail a task allocation than to save 4mbyte of memory.

Andrea Arcangeli

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/