From: Mark_H_Johnson@Raytheon.com
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Amit S. Jain" <amitjain@tifr.res.in>,
linux-mm@kvack.org, owner-linux-mm@kvack.org
Subject: Re: Allocation of kernel memory >128K
Date: Tue, 11 Dec 2001 09:27:36 -0600 [thread overview]
Message-ID: <OF1B7C1C46.B55EBB52-ON86256B1F.00536DEC@hou.us.ray.com> (raw)
Hmm. I don't know if this was necessarily a complete answer. Perhaps a few
extra questions are necessary to clarify what is requested by Amit.
- do you [Amit] want a continuous range of physical pages? If so, why?
- do you want a continuous range of pages in the kernel's virtual address
space? If so, why?
I would not necessarily say that "large amounts of continuous memory is a
bad thing" - rather that it is hard to get, and a costly operation (in
time). For example - a number of existing pages must be moved (or swapped)
to get the area you are requesting. Since this is a big performance hit,
you better have a really good reason for doing so.
If you really need contiguous physical pages - get the bigphysarea patch
and use it. We use it for a shared memory interface between a PC and single
board computers in a VME rack. It works well and is pretty easy to use. It
does have the disadvantage of taking memory away from general use.
If you think you need continuous virtual pages - I suggest putting a little
extra effort into your implementation so it also supports a set of smaller
address ranges. Use the code implementing kiobuf as an example. The added
code should not be much and will save the system a lot of effort in getting
your pages.
--Mark H Johnson
<mailto:Mark_H_Johnson@raytheon.com>
ebiederm@xmiss
ion.com (Eric To: "Amit S. Jain" <amitjain@tifr.res.in>
W. Biederman) cc: linux-mm@kvack.org
Sent by: Subject: Re: Allocation of kernel memory >128K
owner-linux-mm
@kvack.org
12/11/01 04:41
AM
"Amit S. Jain" <amitjain@tifr.res.in> writes:
> I have been working on a module in which I copy large amount of data
fromn
> the user to the kernel area.To do so I allocate using either kmaaloc or
> vmalloc or get_free_pages()large amount of memory(in the range of
> MBytes) in the kernel space.However this attempt is not successful.One
ofmy
> colleagues informed me that in the kernel space it is safe not to
allocate
> large amount of memory at one time,should be kept upto 30K...is he
> right....could you throw more light on this issue.
large amounts of memory are o.k.
large amounts of continuous memory is generally a bad thing.
Allocating everything with multiple calls to get_free_page() should
get the job done.
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next reply other threads:[~2001-12-11 15:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-11 15:27 Mark_H_Johnson [this message]
2001-12-11 18:13 ` Benjamin LaHaise
-- strict thread matches above, loose matches on Subject: below --
2001-12-11 10:06 Amit S. Jain
2001-12-11 10:41 ` Eric W. Biederman
2001-12-12 7:40 ` Amit S. Jain
2001-12-20 3:56 ` Vladimir Dergachev
2001-12-27 11:08 ` Amit S. Jain
2002-01-03 22:59 ` Ravi K
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=OF1B7C1C46.B55EBB52-ON86256B1F.00536DEC@hou.us.ray.com \
--to=mark_h_johnson@raytheon.com \
--cc=amitjain@tifr.res.in \
--cc=ebiederm@xmission.com \
--cc=linux-mm@kvack.org \
--cc=owner-linux-mm@kvack.org \
/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