tigran@sco.COM (Tigran Aivazian) writes:
> Hi,
>
> 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?).
Because allocation of continous blocks > PAGE_SIZE is unreliable. The
process stack/task_struct allocation is the only regular user of 8K pages,
and it uses special hacks in the mm system to make sure it has enough
8k buddies for it purpose. Another user is IP defragmentation, but this
is being fixed.
> 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 think vmalloc in every poll is totally out of question. The patch
needs to be fixed to either allocate only once per process (ugly, eats
lots of memory, needs infrastructure to free on memory pressure), or better
rework the poll interface to support a linked list of poll blocks.
-Andi
-- This is like TV. I don't like TV.- 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:18 EST