| To: | Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: %u-order allocation failed |
| From: | Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx> |
| Date: | Sun, 07 Oct 2001 00:34:22 +0100 |
| Cc: | Anton Blanchard <anton@xxxxxxxxx>, Rik van Riel <riel@xxxxxxxxxxxxxxxx>, Krzysztof Rusocki <kszysiu@xxxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx> |
| In-reply-to: | <Pine.LNX.3.96.1011007002406.18004A-100000@xxxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <Pine.LNX.3.96.1011007002406.18004A-100000@xxxxxxxxxxxxxxxxxxxxx .cz> |
| Reply-to: | Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
--On Sunday, 07 October, 2001 12:31 AM +0200 Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: Sorry, but it can be triggered by _ANY_ VM since buddy allocator was introduced. Just for info, this was circa 1.0.6 :-) (patches were available since 0.99.xxx). And before it was introduced, rather a lot of other things would consistently fail, for instance anything that reassembled packets whose total size was >4k. And currently they still need that. Kernel memory is a limited resource. Contiguous kernel memory more so. Things that need it need to better deal with the lack of it, esp. in transient situations (such as by working round the absence of it, e.g. kiovec in net code, or by causing some freeing and retrying). And, when contiguous kernel memory is short, the allocator could do with some intelligent page freeing to reduce fragmentation. -- Alex Bligh |
| Previous by Date: | Re: %u-order allocation failed, Alex Bligh - linux-kernel |
|---|---|
| Next by Date: | Re: %u-order allocation failed, Alex Bligh - linux-kernel |
| Previous by Thread: | Re: %u-order allocation failed, Alex Bligh - linux-kernel |
| Next by Thread: | Re: %u-order allocation failed, Mikulas Patocka |
| Indexes: | [Date] [Thread] [Top] [All Lists] |