Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\%u\-order\s+allocation\s+failed\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\%u\-order\s+allocation\s+failed\s*$/: 104 ]

Total 104 documents matching your query.

1. %u-order allocation failed (score: 1): Author: Krzysztof Rusocki <kszysiu@xxxxxxxxxxxxxxxxx>; Date: Fri, 5 Oct 2001 13:07:22 +0200; After simple bash fork bombing (about 200 forks) on my UP Celeron/96MB I get quite a lot %u-allocations failed, but only when swap is turned off. When it's turned on, processes are still forking for; /archives/xfs/2001-10/msg00106.html (9,085 bytes)
2. Re: %u-order allocation failed (score: 1): Author: Rik van Riel <riel@xxxxxxxxxxxxxxxx>; Date: Fri, 5 Oct 2001 08:59:19 -0300 (BRST); This is perfectly normal behaviour: 1) on your system, you have no process limit configured for yourself so you can start processes until all resources (memory, file descriptors, ...) are used 2) whe; /archives/xfs/2001-10/msg00107.html (9,311 bytes)
3. Re: %u-order allocation failed (score: 1): Author: Seth Mos <knuffie@xxxxxxxxx>; Date: Fri, 5 Oct 2001 22:18:39 +0200 (CEST); Fair enough. So it needs a handbrake in case of a emergency? The box at work deadlocks or crashes. I can hardly call that normal operational behaviour. I have a Dell PE 2500 (Serverworks LE) with 2GB; /archives/xfs/2001-10/msg00120.html (10,222 bytes)
4. Re: %u-order allocation failed (score: 1): Author: Rik van Riel <riel@xxxxxxxxxxxxxxxx>; Date: Fri, 5 Oct 2001 17:22:40 -0300 (BRST); Ohh duh, IIRC there are a bunch of highmem bugs in -linus which are fixed in -ac. Can you reproduce the bug with an -ac kernel ? regards, Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/; /archives/xfs/2001-10/msg00121.html (8,978 bytes)
5. Re: %u-order allocation failed (score: 1): Author: Seth Mos <knuffie@xxxxxxxxx>; Date: Fri, 5 Oct 2001 22:31:38 +0200 (CEST); Fitting XFS onto a -ac kernel should be fun :-( I will try this over the weekend or get a redhat kernel going which is also -ac based. That would come in handy for other people using XFS since a lot; /archives/xfs/2001-10/msg00123.html (9,233 bytes)
6. Re: %u-order allocation failed (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Fri, 05 Oct 2001 15:43:16 -0500; Its not that that simple - I tried before I got dragged kicking and screaming back into some Irix stuff. Just running mongo on ext2 on a HIGHMEM ac kernel should show if things are better there - si; /archives/xfs/2001-10/msg00126.html (9,871 bytes)
7. Re: %u-order allocation failed (score: 1): Author: Seth Mos <knuffie@xxxxxxxxx>; Date: Fri, 5 Oct 2001 23:09:01 +0200 (CEST); I don't have a HIGHMEM box without XFS filesystems. So i have to merge both -ac and the xfs tree to test it. I can reformat the box ofcourse but that would mean next week. If I can win a day and spar; /archives/xfs/2001-10/msg00130.html (9,895 bytes)
8. Re: %u-order allocation failed (score: 1): Author: Seth Mos <knuffie@xxxxxxxxx>; Date: Sat, 6 Oct 2001 00:16:11 +0200 (CEST); I was refering to the mundane load of mongo.pl with 5 processes. Something the systems should withstand. If you have more then 10GB of database to access you would want it to work. I am not talking a; /archives/xfs/2001-10/msg00136.html (10,157 bytes)
9. Re: %u-order allocation failed (score: 1): Author: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 16:00:21 +0200 (CEST); No, it's not normal. It is long-standing bug - I think from 2.2 kernels. You know that without swap and with certain memory allocation strategy (when process in a loop allocates one anonymous page,; /archives/xfs/2001-10/msg00147.html (11,126 bytes)
10. Re: %u-order allocation failed (score: 1): Author: Rik van Riel <riel@xxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 11:03:47 -0300 (BRST); Please send patches to get rid of the buddy allocator while still making it possible to allocate contiguous chunks of memory. If you have any idea on how to fix things, this would be a good time to l; /archives/xfs/2001-10/msg00148.html (10,053 bytes)
11. Re: %u-order allocation failed (score: 1): Author: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 16:44:43 +0200 (CEST); Here goes the fix. (note that I didn't try to compile it so there may be bugs, but you see the point). kmalloc should be fixed too (used badly for example in select.c - and yes - I have seen real wor; /archives/xfs/2001-10/msg00150.html (12,774 bytes)
12. Re: %u-order allocation failed (score: 1): Author: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 17:31:26 +0200 (CEST); This is enhanced version of a patch that fixes select and poll as well. Again - not compiled, not tried. Mikulas diff -u -r linux-orig/fs/select.c linux/fs/select.c -- linux-orig/fs/select.c Sat Oct; /archives/xfs/2001-10/msg00151.html (15,305 bytes)
13. Re: %u-order allocation failed (score: 1): Author: Rik van Riel <riel@xxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 13:58:16 -0300 (BRST); So what are you going to do when your 64MB of vmalloc space runs out ? Rik -- DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/ (volunteers needed) http://www.surriel.com/ http://distro.conectiva; /archives/xfs/2001-10/msg00154.html (13,031 bytes)
14. Re: %u-order allocation failed (score: 1): Author: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 19:48:52 +0200 (CEST); Make larger vmalloc space :-) Virtual memory costs very little. Besides 64M / 8k = 8192 - so it runs out at 8192 processes. Of course vmalloc space can overflow - but it overflows only when the machi; /archives/xfs/2001-10/msg00155.html (10,913 bytes)
15. Re: %u-order allocation failed (score: 1): Author: Alex Bligh - linux-kernel <linux-kernel@xxxxxxxxxxx>; Date: Sat, 06 Oct 2001 18:59:34 +0100; --On Saturday, 06 October, 2001 4:44 PM +0200 Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: Here goes the fix. (note that I didn't try to compile it so there may be bugs, but you see the; /archives/xfs/2001-10/msg00156.html (10,789 bytes)
16. Re: %u-order allocation failed (score: 1): Author: Anton Blanchard <anton@xxxxxxxxx>; Date: Sun, 7 Oct 2001 04:12:01 +1000; vmalloc space is also much worse for tlb usage when the main kernel mapping uses large hardware ptes. Ingo and davem pointed this out to me recently when I wanted to allocate the pagecache hash usin; /archives/xfs/2001-10/msg00157.html (10,805 bytes)
17. Re: %u-order allocation failed (score: 1): Author: Russell Cattelan <cattelan@xxxxxxxxxxx>; Date: 06 Oct 2001 15:35:22 -0500; Actually it's not to bad ... I've been merging the with the ac kernels as the Mandrake people need them. I have a 2.4.9 ac 16 patch mostly worked out... if you want to finish it I could send it to yo; /archives/xfs/2001-10/msg00159.html (9,776 bytes)
18. Re: %u-order allocation failed (score: 1): Author: Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 21:13:00 +0200 (CEST); It uses vmalloc only when __GFP_VMALLOC flag is given - and so it is expected to not use __GFP_VMALLOC flag in IRQ. NOTE: no allocations in IRQ are safe. Not only high-order ones. Allocation in IRQ; /archives/xfs/2001-10/msg00161.html (9,440 bytes)
19. Re: %u-order allocation failed (score: 1): Author: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>; Date: Sat, 6 Oct 2001 22:13:03 +0200; I missed the beginning of the thread, sorry if that question was already answered, What about all the code that still consider kmalloc'ed memory is safe for use with virt_to_bus and friends and is c; /archives/xfs/2001-10/msg00163.html (9,375 bytes)
20. Re: %u-order allocation failed (score: 1): Author: Russell Cattelan <cattelan@xxxxxxxxxxx>; Date: 06 Oct 2001 15:32:57 -0500; Actually it's not to bad ... I've been merging the with the ac kernels as the Mandrake people need them. I have a 2.4.9 ac 16 patch mostly worked out... if you want to finish it I could send it to yo; /archives/xfs/2001-10/msg00164.html (9,596 bytes)

Current List: 1 - 20
Page: [1] [2] [3] [4] [5] [6]