Messages in this thread | | | Subject | Re: [Patch] Polling on more than 16000 file descriptors | From | Andi Kleen <> | Date | 18 Jan 2000 15:56:32 +0100 |
| |
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/
| |