Also sprach Andi Kleen:
} > 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.
Maybe if vmalloc was the "thing to use" for allocations and have it call
kmalloc/gfp whenever necessary? Could be a big hassle, though.
Anyway, I tried implementing the linked-list version of the poll(). It
was wrought with problems. The code looked fine (I submitted an alternate
patch about it awhile ago...It should be in the archives), but the
poll()ing would simply poll over and over in some cases...
-- || Bill Wendling firstname.lastname@example.org
- 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:18 EST