Re: Are there some potential problems that I should be aware of if I allocate the memory which doesn't have any relation to peripheral hardwares(i.e. DMA, PCI, serial port and etc) by vmalloc() instead of kmalloc()?

["孙世龙 sunshilong" <sunshilong369@gmail.com>]

Hi, Valdis Klētnieks,Greg KH

Thanks a lot to both of you.

>As I mentioned a few days ago, the fact that a high-order allocation failed
>does not necessarily mean a total failure, as often the driver can instead
>allocate several smaller areas.
The related code snippet is not used for a driver, it's a part of the real-time
system.I don't modify too many code snippets of it.

>First, Linux is not a real-time OS.  Second, "real time" doesn't automatically
>imply those two options have to be disabled.  It's trickier to do it when you
>have hard real-time limits, but it's not impossible.
Excuse me, what do you mean by "It's trickier to do it when you have hard
real-time limits, but it's not impossible."? Could you please explain that in
simpler words?

I have to disable these options since the real-time patch requires to do it.

>Having said that about migration and compaction, anybody sane who's writing for
>an actual real-time system already knows *exactly* how much memory the system
>will use, and the critical allocations are done at system startup to guarantee
>that (a) the allocations succeed and (b) most of the memory is pre-allocated
>with little chance of causing fragmentation.
I fully understand what you mean. Your conclusion is quite right, but
there needs
a hypothesis(i.e. your have only a real-time process on the platform and don't
restart it now and then. What would happen if many real-time processes and
non-real-time processes are running on the same platform？ What would happen
if the testers restart them now and then? it causes memory
fragmentation indeed.)
lie behind it.

And "exactly how much memory of each program(i.e. instead of system) will use"
is determined by the specific applications(i.e. only the user
application programmers
know how much memory the program needs). But the memory should be allocated
before the app is started(i.e. before the entry of the main()
function), you should not
use malloc() to acquire memory in your application code snippet.For
details, see the
example below.

>So as per the above - you allocate one struct array at driver load time for
>this stuff.  You already know how big the structure/array has to be based on
>the maximum number of devices or whatever you're trying to track.
>And if you don't know the maximum, you're not doing real time programming. Or
>at least not correctly.
Not at the driver load time, but the load time of the real-time
process(i.e. before
the entry of the main() function). It needs to allocate(i.e. use
vmalloc) a huge memory
(i.e. for example 80MB, maybe 50MB (how much memory is suitable is decided by
the specific applications.) used by the user application later. And
that's ok to allocate
so huge memory size by vmalloc() and no error complained by the kernel.
As it needs a struct array to identify the usage of the said huge
memory, the real-time
patch uses kmalloc() to do the allocation and the page allocation
failure occurs.
I think there is no need to use kmalloc() at all. I want to use
vmalloc() or kmalloc()
instead of kmalloc() despite kmalloc() is more efficient.
How do you think about it?

Thank you for your generous help.
Look forward to hearing from you.
Best Regards.
sunshilong

Valdis Klētnieks <valdis.kletnieks@vt.edu> 于2020年6月27日周六 上午1:22写道：
>
> On Fri, 26 Jun 2020 23:36:05 +0800, 孙世龙 sunshilong said:
> > Thank you for your attention to this matter.
> >
> > >Why are you having so many issues in allocating memory?
> > I often saw the page allocation failure recently. I must resolve this problem.
>
> As I mentioned a few days ago, the fact that a high-order allocation failed
> does not necessarily mean a total failure, as often the driver can instead
> allocate several smaller areas.
>
> > I have no choice other than disabling these options
> > (i.e. CONFIG-MIGRATION and CONFIG-COMPACTION)
> > since I am using a real-time OS.
>
> First, Linux is not a real-time OS.  Second, "real time" doesn't automatically
> imply those two options have to be disabled.  It's trickier to do it when you
> have hard real-time limits, but it's not impossible.
>
> > The current code snippet is using kmalloc() and often encounter the
> > aforementioned problem.
>
> Having said that about migration and compaction, anybody sane who's writing for
> an actual real-time system already knows *exactly* how much memory the system
> will use, and the critical allocations are done at system startup to guarantee
> that (a) the allocations succeed and (b) most of the memory is pre-allocated
> with little chance of causing fragmentation.
>
> > So I want to use vmalloc() instead of kmalloc(). What do you think about it?
> > The memory to be allocated doesn't have any relation to any peripheral
> > hardware (i.e. DMA, PCI, serial port, etc) indeed. It's just used to
> > store a struct
> > array which indicates the usage of other resources.
>
> So as per the above - you allocate one struct array at driver load time for
> this stuff.  You already know how big the structure/array has to be based on
> the maximum number of devices or whatever you're trying to track.
>
> And if you don't know the maximum, you're not doing real time programming. Or
> at least not correctly.
>

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies