Reto Baettig writes:
> The RPC server needs lots of 2MB receive buffers which are
> allocated using vmalloc because the NIC has its own pagetables.
Why not just allocate the page seperately and keep track of
where they are, since the NIC has all the page tabling facilities
on it's end, the cpu
Ingo Molnar wrote:
> question: what is this application, and why does it need so much virtual
> memory? vmalloc()-able memory is maximized to 128 MB right now, and
> increasing it conflicts with directly mapping RAM, so generally it's a
> good idea to avoid vmalloc() as much as possible.
We imple
> We have an application that makes extensive use of vmalloc (we need
> lots of large virtual contiguous buffers. The buffers don't have to be
> physically contiguous).
So you could actually code around that. If you have them virtually contiguous
for mmap for example then you can actually mmap ar
In article <[EMAIL PROTECTED]>,
Reto Baettig <[EMAIL PROTECTED]> wrote:
>
>We would volounteer to improve vmalloc if there is any chance of
>getting it into the main kernel tree. We also have an idea how we
>Could do that (quite similar to the process address space management):
>
>1. Create
On Fri, 23 Feb 2001, Reto Baettig wrote:
> We have an application that makes extensive use of vmalloc (we need
> lots of large virtual contiguous buffers. The buffers don't have to be
> physically contiguous).
question: what is this application, and why does it need so much virtual
memory? vmal
Hi
We have an application that makes extensive use of vmalloc (we need
lots of large virtual contiguous buffers. The buffers don't have to be
physically contiguous).
vmalloc/vfree is very slow when the vmlist gets long.
I don't know if this problem is already on a todo list or if we are the
fir
6 matches
Mail list logo
