So, I changed my code such that vmalloc() is only called in driver's open function,
and interrupt handler only access the memory already allocated by vmalloc().
Then I have a question.
Does this memory area allocated by vmalloc() have a possibility to be paged out?
If this area paged out, interrupt handler cannot access the area(because
interrupt handler must sleep until page-in handler done.)
Please help me.
Thanks !!!
No... vmalloc differs from kmalloc in that it allocates individual pages and
rearranges page tables so that the memory looks continuous. I don't think
that these pages may be swapped out.
If you would use kmalloc, the returned memory would be really continuous,
and not just look like it as with possibly with vmalloc.
Tuukka Toivonen <tuu...@killspam.ee.oulu.finland.invalid> wrote in message news:<slrnc8f57l....@s-inf-pc92.oulu.fi>...
> If you would use kmalloc, the returned memory would be really continuous,
> and not just look like it as with possibly with vmalloc.
Yes, at first I used kmalloc, however
calling kmalloc() many times may cause kernel crash (if allocated areas
are not released by kfree().)
So I decided to get a big memory area at drive open() routine, and
if my driver(include interrupt handler) only access a portion of this memory area
, linux kernel should not hang up (if not paged out).
Max allocatable size of one kmalloc() is 128k, so I decided to use vmalloc().
> No... vmalloc differs from kmalloc in that it allocates individual pages and
> rearranges page tables so that the memory looks continuous. I don't think
> that these pages may be swapped out.
>
Thanks for your suggestion
I'll try to test my driver for a long time.
Of course you must free memory when you are done with it.
This is kernel code, there is no-one to clean up after you.
> So I decided to get a big memory area at drive open() routine, and
> if my driver(include interrupt handler) only access a portion of this memory area
> , linux kernel should not hang up (if not paged out).
You really should not allocate more than you need. Kernel
memory is a sparse resource.
>
> Max allocatable size of one kmalloc() is 128k, so I decided to use vmalloc().
That depends. In some configurations kmalloc will allow
more than 128k. But if memory has been fragmented, don't
expect requests for more than 8KB to be possible. But even
vmalloc should be used with care. There is a limit of IIRC
64MB on the total amount of memory that can be allocated
using vmalloc.
--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use ab...@mk.lir.dk and kas...@mk.lir.dk
/* Would you like fries with that? */
Currently I'm trying to make a simple protocol stack using
kernel protocol interface such as "struct proto".
Received packets should be saved in this protocol-driver, if application
not yet read packets.
So, my-driver cannot call kfree() until packets are copied to application.
Too many in-coming packets saved by kmalloc(), cause exhaustion of
kernel memory, and in some cases, cause kernel hang up.
So, I decided to make a big memory area to store in-coming packets.
> That depends. In some configurations kmalloc will allow
> more than 128k. But if memory has been fragmented, don't
> expect requests for more than 8KB to be possible. But even
> vmalloc should be used with care. There is a limit of IIRC
> 64MB on the total amount of memory that can be allocated
> using vmalloc.
Thank you very much. 64MB is a big size.
I'll try to use vmalloc() and test my-driver.
In case of too many incoming packets, you will need to
drop some of them. There are obviously a lot of possible
ways to know when you will need to start droping packets.
> In case of too many incoming packets, you will need to
> drop some of them. There are obviously a lot of possible
> ways to know when you will need to start droping packets.
Yes. I think your suggestion is right. However, currently
I have a plan to prepare a linux-machine of exclusive use,
only in order to run my-driver.
So I'd like to use all available kernel-memory for my-driver
by easy method.
Thanks !!