Dear Alan,
Recently I suggested to use vmalloc() for large number of descriptors (and
continue using kmalloc() for smaller numbers) as a fix for the nfds>16390
bug that is on the list you posted.
The patch was on
http://www.ocston.org/~tigran/patches/pollfix-2.3.40-p1.patch
However, if you prefer the solution to lie in the slab allocator
and not in sys_poll(), i.e. to allow general purpose 256K requests, here
is the patch that does just that (assumes gfp layer "just works" (seems
to)):
http://www.ocston.org/~tigran/patches/slab-256K.patch
The disadvantage of first patch is that it makes poll very slow when
nfds>16390 (better than nothing, though).
Regards,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
--- 2340-p5/mm/slab.c Tue Jan 18 10:48:32 2000
+++ linux/mm/slab.c Tue Jan 18 11:30:17 2000
@@ -299,10 +299,10 @@
#define SLAB_C_MAGIC 0x4F17A36DUL
/* maximum size of an obj (in 2^order pages) */
-#define SLAB_OBJ_MAX_ORDER 5 /* 32 pages */
+#define SLAB_OBJ_MAX_ORDER 6 /* 64 pages */
/* maximum num of pages for a slab (prevents large requests to the VM layer) */
-#define SLAB_MAX_GFP_ORDER 5 /* 32 pages */
+#define SLAB_MAX_GFP_ORDER 6 /* 64 pages */
/* the 'preferred' minimum num of objs per slab - maybe less for large objs */
#define SLAB_MIN_OBJS_PER_SLAB 4
@@ -346,6 +346,7 @@
{32768, NULL},
{65536, NULL},
{131072, NULL},
+ {262144, NULL},
{0, NULL}
};
@@ -368,7 +369,8 @@
"size-16384",
"size-32768",
"size-65536",
- "size-131072"
+ "size-131072",
+ "size-262144"
};
/* internal cache of cache description objs */
-
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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:17 EST