Messages in this thread | | | Date | Wed, 17 Mar 1999 00:54:56 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: vfork: out of memory, when there's plenty of swap free |
| |
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/
| |