> Hi,
>
> This is the first attempt at this specific task so
please be gentle.
>
> The thing I am unhappy about is the extra vmalloc/copy
in read_kmem().
I don\'t like the vmalloc():
* vmalloc must flush all TLB\'s on alls CPU\'s, ie it\'s
extremely slow.
* it\'s superflous: there are no atomicity guarantees for
/dev/kmem, what about allocating a single page, and
adding a short loop:
while(len > 0) {
int cur_len = len;
if(cur_len > PAGE_SIZE)
cur_len = PAGE_SIZE;
...
len -= cur_len;
}
> Ultimately, it is not a problem because /dev/kmem
access is not
> performance critical whilst the use of
vmalloc/vfree/ioremap (esp in
> drivers) may be very critical.
I never benchmarked it myself, but Christoph benchmarked
the shm code: vmalloc() was so slow that he replaced it
with an indirect allocation.
A driver that frequently calls ioremap() will be slow -
with or without lock_kernel().
-- Manfred----------------------------------------------------- This mail sent through IMP: http://web.horde.org/imp/
- 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/