On Tue, 2007-01-16 at 00:21 -0500, David Moore wrote:
> On Mon, 2007-01-15 at 16:43 -0500, Kristian Høgsberg wrote:
> > On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > again the best way is for you to provide an mmap method... you can then
> > > fill in the pages and keep that in
Hi,
> I think you've convinced me that vmalloc is not a good choice when a
> driver needs a large buffer (many megabytes) for DMA.
Yep. bttv used to do that long time ago, and some people used to run
into trouble because the nvidia driver used lots of vmalloc address
space ...
> In this
Hi,
I think you've convinced me that vmalloc is not a good choice when a
driver needs a large buffer (many megabytes) for DMA.
Yep. bttv used to do that long time ago, and some people used to run
into trouble because the nvidia driver used lots of vmalloc address
space ...
In this case,
On Tue, 2007-01-16 at 00:21 -0500, David Moore wrote:
On Mon, 2007-01-15 at 16:43 -0500, Kristian Høgsberg wrote:
On 1/15/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
again the best way is for you to provide an mmap method... you can then
fill in the pages and keep that in some sort of
On Mon, 2007-01-15 at 16:43 -0500, Kristian Høgsberg wrote:
> On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > again the best way is for you to provide an mmap method... you can then
> > fill in the pages and keep that in some sort of array; this is for
> > example also what the DRI/DRM
On Tuesday 16 January 2007 06:43, Kristian Høgsberg wrote:
> On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > there is a lot of pain involved with doing things this way, it is a TON
> > better if YOU provide the memory via a custom mmap handler for a device
> > driver.
> > (there are a
On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> However, what I'd really like to do is to leave it to user space to
> allocate the memory as David describes. In the transmit case, user
> space allocates memory (malloc or mmap) and loads the payload into
> that buffer.
there is a lot
> However, what I'd really like to do is to leave it to user space to
> allocate the memory as David describes. In the transmit case, user
> space allocates memory (malloc or mmap) and loads the payload into
> that buffer.
there is a lot of pain involved with doing things this way, it is a TON
On 1/15/07, David Moore <[EMAIL PROTECTED]> wrote:
On Mon, 2007-01-15 at 10:20 -0800, Arjan van de Ven wrote:
> if you need that much you probably should redesign your algorithms to
> not need vmalloc in the first place
I think you've convinced me that vmalloc is not a good choice when a
On Mon, 2007-01-15 at 10:20 -0800, Arjan van de Ven wrote:
> if you need that much you probably should redesign your algorithms to
> not need vmalloc in the first place
I think you've convinced me that vmalloc is not a good choice when a
driver needs a large buffer (many megabytes) for DMA.
> >
> I've used vmalloc in the past, and not had a problem, but it is a fair
> question, how do you find out how much space is available? Other than a
> binary vmalloc/release loop.
that's a really hard question since it's dynamic;
I suppose a good rule of thumb is "never expect more than
Arjan van de Ven wrote:
On Sun, 2007-01-14 at 20:19 +0100, Stefan Richter wrote:
On 10 Jan, Peter Antoniac wrote:
[...]
Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
running? I couldn't find any standard way to do that (something to apply to
GNU Linux and the like).
Arjan van de Ven wrote:
On Sun, 2007-01-14 at 20:19 +0100, Stefan Richter wrote:
On 10 Jan, Peter Antoniac wrote:
[...]
Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
running? I couldn't find any standard way to do that (something to apply to
GNU Linux and the like).
I've used vmalloc in the past, and not had a problem, but it is a fair
question, how do you find out how much space is available? Other than a
binary vmalloc/release loop.
that's a really hard question since it's dynamic;
I suppose a good rule of thumb is never expect more than 16Mb to
On Mon, 2007-01-15 at 10:20 -0800, Arjan van de Ven wrote:
if you need that much you probably should redesign your algorithms to
not need vmalloc in the first place
I think you've convinced me that vmalloc is not a good choice when a
driver needs a large buffer (many megabytes) for DMA.
In
On 1/15/07, David Moore [EMAIL PROTECTED] wrote:
On Mon, 2007-01-15 at 10:20 -0800, Arjan van de Ven wrote:
if you need that much you probably should redesign your algorithms to
not need vmalloc in the first place
I think you've convinced me that vmalloc is not a good choice when a
driver
However, what I'd really like to do is to leave it to user space to
allocate the memory as David describes. In the transmit case, user
space allocates memory (malloc or mmap) and loads the payload into
that buffer.
there is a lot of pain involved with doing things this way, it is a TON
On 1/15/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
However, what I'd really like to do is to leave it to user space to
allocate the memory as David describes. In the transmit case, user
space allocates memory (malloc or mmap) and loads the payload into
that buffer.
there is a lot of
On Tuesday 16 January 2007 06:43, Kristian Høgsberg wrote:
On 1/15/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
there is a lot of pain involved with doing things this way, it is a TON
better if YOU provide the memory via a custom mmap handler for a device
driver.
(there are a lot of
On Mon, 2007-01-15 at 16:43 -0500, Kristian Høgsberg wrote:
On 1/15/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
again the best way is for you to provide an mmap method... you can then
fill in the pages and keep that in some sort of array; this is for
example also what the DRI/DRM layer
On Monday 15 January 2007 13:14, Peter Antoniac wrote:
> This is more the answer that I expect. But is there a way, function or
> constant from **libdc** that can give you the answer, or you have to get it
...
What was I thinking... not from libdc but from LIBC :)
-
To unsubscribe from this list:
On Monday 15 January 2007 05:31, Stefan Richter wrote:
> On 14 Jan, Arjan van de Ven wrote:
> > vmalloc space is limited; you really can't assume you can get any more
> > than 64Mb or so (and even then it's thight on some systems already);
>
> I suppose "grep VmallocChunk /proc/meminfo" shows what
On Sun, 2007-01-14 at 21:31 +0100, Stefan Richter wrote:
> On 14 Jan, Arjan van de Ven wrote:
> > vmalloc space is limited; you really can't assume you can get any more
> > than 64Mb or so (and even then it's thight on some systems already);
>
> I suppose "grep VmallocChunk /proc/meminfo" shows
On 14 Jan, Arjan van de Ven wrote:
> vmalloc space is limited; you really can't assume you can get any more
> than 64Mb or so (and even then it's thight on some systems already);
I suppose "grep VmallocChunk /proc/meminfo" shows what is available?
> it really sounds like vmalloc space isn't the
On Sun, 2007-01-14 at 20:19 +0100, Stefan Richter wrote:
> On 10 Jan, Peter Antoniac wrote:
> [...]
> > Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
> > running? I couldn't find any standard way to do that (something to apply to
> > GNU Linux and the like). All the
On 10 Jan, Peter Antoniac wrote:
[...]
> Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
> running? I couldn't find any standard way to do that (something to apply to
> GNU Linux and the like). All the things I could get were the default value
> being 128MiB :) and that
On 10 Jan, Peter Antoniac wrote:
[...]
Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
running? I couldn't find any standard way to do that (something to apply to
GNU Linux and the like). All the things I could get were the default value
being 128MiB :) and that is
On Sun, 2007-01-14 at 20:19 +0100, Stefan Richter wrote:
On 10 Jan, Peter Antoniac wrote:
[...]
Problem is: how to get the VMALLOC_RESERVED value for the kernel that is
running? I couldn't find any standard way to do that (something to apply to
GNU Linux and the like). All the things I
On 14 Jan, Arjan van de Ven wrote:
vmalloc space is limited; you really can't assume you can get any more
than 64Mb or so (and even then it's thight on some systems already);
I suppose grep VmallocChunk /proc/meminfo shows what is available?
it really sounds like vmalloc space isn't the right
On Sun, 2007-01-14 at 21:31 +0100, Stefan Richter wrote:
On 14 Jan, Arjan van de Ven wrote:
vmalloc space is limited; you really can't assume you can get any more
than 64Mb or so (and even then it's thight on some systems already);
I suppose grep VmallocChunk /proc/meminfo shows what is
On Monday 15 January 2007 05:31, Stefan Richter wrote:
On 14 Jan, Arjan van de Ven wrote:
vmalloc space is limited; you really can't assume you can get any more
than 64Mb or so (and even then it's thight on some systems already);
I suppose grep VmallocChunk /proc/meminfo shows what is
On Monday 15 January 2007 13:14, Peter Antoniac wrote:
This is more the answer that I expect. But is there a way, function or
constant from **libdc** that can give you the answer, or you have to get it
...
What was I thinking... not from libdc but from LIBC :)
-
To unsubscribe from this list:
32 matches
Mail list logo
