| To: | mikulas@xxxxxxxxxxxxxxxxxxxxxxxx |
|---|---|
| Subject: | Re: %u-order allocation failed |
| From: | Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> |
| Date: | Sat, 6 Oct 2001 22:13:41 +0100 (BST) |
| Cc: | anton@xxxxxxxxx (Anton Blanchard), riel@xxxxxxxxxxxxxxxx (Rik van Riel), kszysiu@xxxxxxxxxxxxxxxxx (Krzysztof Rusocki), linux-xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx |
| In-reply-to: | <Pine.LNX.3.96.1011006203014.7808A-100000@artax.karlin.mff.cuni.cz> from "Mikulas Patocka" at Oct 06, 2001 09:07:31 PM |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
> It is perfectly OK to have a bit slower access to task_struct with > probability 1/1000000. Except that you added a bug where some old driver code would crash the machine by doing so. > Yes, but there are still other dangerous usages of kmalloc and > __get_free_pages. (The most offending one is in select.c) Nothing dangeorus there. The -ac vm isnt triggering these cases. > not abort his operation when it happens. Instead - they are trying to make > high-order allocations fail less often :-/ How should random > Joe-driver-developer know, that kmalloc(4096) is safe and kmalloc(4097) is > not? 4096 is not safe - there is no safe size for a kmalloc, you can always run out of memory - deal with it. Alan |
| Previous by Date: | Re: We have a mail loop!, Russell Cattelan |
|---|---|
| Next by Date: | kernel panic with preemtive and XFS kernelpatch, Knut J Bjuland |
| Previous by Thread: | Re: %u-order allocation failed, Mikulas Patocka |
| Next by Thread: | Re: %u-order allocation failed, Mikulas Patocka |
| Indexes: | [Date] [Thread] [Top] [All Lists] |