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()?

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200626/61fc4e63/attachment.sig>