I just noticed your patch but why do you use vmalloc() above just 1 page
and not the kmalloc()'s limit of 128K? Surely below 128K kmalloc() is
faster than vmalloc()? (I know ipc_alloc() does the same but why?).
And, btw, since now the number of users of vmalloc() in
performance-critical paths is growing, perhaps it is worth to come back to
the patch I submitted for review ages ago that adds vmlist_lock rw
spinlock and makes vmalloc() SMP-safe?
I.e. why should we continue adding lock/unlock_kernel around
vmalloc()/vfree() when we can get rid of the issue altogether.
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
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