Jes Sorensen schrieb:
> Christian Hildner <[email protected]> writes:
>
> > David,
> >
> > you proposed me to use alloc_pages() instead of kmalloc() in order
> > to get memory bigger than the 128K limit of the kmalloc() call. But
> > even driver-developers don't want to handle with the page struct
> > unless this is unavoidable. Which are the disadvantages of
> > increasing the size limit of kmalloc() to 256K, 512K or 1M since
> > machines are getting bigger and 64Bit machines break with current
> > memory limitations?
>
> Because drivers needs to work on all architectures and relying on
> different hahavior from kmalloc() is bad.
>
> Jes
Jes,
sorry for being unclear. I mean from increasing the kmalloc() size-limit
all platforms would benefit.
Christian
PS: David, I am looking forward getting your book. You are doing a great
job.
>>>>> "Christian" == Christian Hildner <[email protected]> writes:
Christian> Jes Sorensen schrieb:
>> Because drivers needs to work on all architectures and relying on
>> different hahavior from kmalloc() is bad.
Christian> sorry for being unclear. I mean from increasing the kmalloc()
Christian> size-limit all platforms would benefit.
Thats not really a good idea, and definately not something you want to
rely on. A lot of architectures are still stuck with 4KB pages and
trying to allocate 128KB on larger in one chunk is likely to fail after
the system has been running for a while. On an ia64 with 16KB or 64KB
pages it's fairly likely it will work, but this is not necessarily a
good idea to do for other archs. If you need such a large block of
memory, vmalloc() is the real way to go.
Jes