linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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/

             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