kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: 孙世龙 sunshilong <sunshilong369@gmail.com>
Cc: Greg KH <greg@kroah.com>, Kernelnewbies@kernelnewbies.org
Subject: 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()?
Date: Fri, 26 Jun 2020 13:22:23 -0400	[thread overview]
Message-ID: <67284.1593192143@turing-police> (raw)
In-Reply-To: <CAAvDm6aZc5js0NKJZPdcTjNkKgg+3QGXLPyYaVosjgdvJcZq5w@mail.gmail.com>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset=us-ascii, Size: 1861 bytes --]

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.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

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

  reply	other threads:[~2020-06-26 17:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26  8:30 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
2020-06-26 14:13 ` Greg KH
2020-06-26 15:36   ` 孙世龙 sunshilong
2020-06-26 17:22     ` Valdis Klētnieks [this message]
2020-06-27  5:16       ` 孙世龙 sunshilong
2020-06-27  5:23         ` Greg KH
2020-06-27  6:00           ` 孙世龙 sunshilong
2020-06-27  7:05             ` Greg KH
2020-06-27  5:05     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=67284.1593192143@turing-police \
    --to=valdis.kletnieks@vt.edu \
    --cc=Kernelnewbies@kernelnewbies.org \
    --cc=greg@kroah.com \
    --cc=sunshilong369@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).