linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: akpm@digeo.com
Cc: rusty@rustcorp.com.au, dipankar@in.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kmalloc_percpu
Date: Mon, 05 May 2003 20:37:58 -0700 (PDT)	[thread overview]
Message-ID: <20030505.203758.48517285.davem@redhat.com> (raw)
In-Reply-To: <20030505212816.7cb0ec49.akpm@digeo.com>

   From: Andrew Morton <akpm@digeo.com>
   Date: Mon, 5 May 2003 21:28:16 -0700
   
   It's OK as long as nobody uses the feature!
   
I think this is closer to say, allocation of kmap types,
than it is to vmalloc() et al. (as you suggest).

   Ho-hum.  Can the magical constant become a __setup thing?
   
Remember that there are physical limitations, for example
on ia64, as to how big this thing can be.  So whatever any
of us think about physical limitations, we have to deal with
them anyways :-)

I think firstly, that we should define that this isn't
something you be doing after module_init()  (ie. your
->open() example, that's rediculious).  Ideas on how to
enforce this are welcome.

Next, we can calculate how much per-cpu space all the modules
need.  And because we can do that, we can preallocate slots
if we wanted to in order to deal with whatever theoretical
fragmentation problems you think exist (much like how Jakub Jelink's
prelinking works).

I personally don't know how smart it is to let random modules use
kmalloc_percpu() with impunity.  But aparently someone thinks
there is some value in that.

  reply	other threads:[~2003-05-06  4:32 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-05  8:08 [PATCH] kmalloc_percpu Rusty Russell
2003-05-05  8:47 ` Andrew Morton
2003-05-06  0:47   ` Rusty Russell
2003-05-06  1:52     ` Andrew Morton
2003-05-06  2:11       ` David S. Miller
2003-05-06  4:08         ` Rusty Russell
2003-05-06  3:40           ` David S. Miller
2003-05-06  5:02             ` Andrew Morton
2003-05-06  4:16               ` David S. Miller
2003-05-06  5:48                 ` Andrew Morton
2003-05-06  5:35                   ` David S. Miller
2003-05-06  6:55                     ` Andrew Morton
2003-05-06  5:57                       ` David S. Miller
2003-05-06  7:22                         ` Andrew Morton
2003-05-06  6:15                           ` David S. Miller
2003-05-06  7:34                             ` Andrew Morton
2003-05-06  8:42                               ` William Lee Irwin III
2003-05-06 14:38                               ` Martin J. Bligh
2003-05-06  7:20                       ` Dipankar Sarma
2003-05-06  8:28                       ` Rusty Russell
2003-05-06  8:47                         ` Andrew Morton
2003-05-07  1:57                           ` Rusty Russell
2003-05-07  2:41                             ` William Lee Irwin III
2003-05-07  4:03                               ` Paul Mackerras
2003-05-07  4:22                                 ` William Lee Irwin III
2003-05-07  4:56                                   ` Paul Mackerras
2003-05-07  5:19                                     ` William Lee Irwin III
2003-05-07  4:10                                       ` Martin J. Bligh
2003-05-07 12:13                                         ` William Lee Irwin III
2003-05-07  4:15                               ` Rusty Russell
2003-05-07  5:37                             ` Andrew Morton
2003-05-08  0:53                               ` Rusty Russell
2003-05-06 14:41                         ` Martin J. Bligh
2003-05-06  6:42                   ` Andrew Morton
2003-05-06  5:39                     ` David S. Miller
2003-05-06  6:57                       ` Andrew Morton
2003-05-06  7:25                         ` Jens Axboe
2003-05-06 10:41                           ` Ingo Oeser
2003-05-06 16:05                         ` Bryan O'Sullivan
2003-05-06  8:06               ` Rusty Russell
2003-05-06  5:03             ` Dipankar Sarma
2003-05-06  4:28           ` Andrew Morton
2003-05-06  3:37             ` David S. Miller [this message]
2003-05-06  4:11       ` Rusty Russell
2003-05-06  5:07   ` Ravikiran G Thirumalai
2003-05-06  8:03     ` Rusty Russell
2003-05-06  9:23       ` David S. Miller
2003-05-06  9:34       ` Ravikiran G Thirumalai
2003-05-06  9:38         ` Dipankar Sarma
2003-05-07  2:14         ` Rusty Russell
2003-05-07  5:51 ` Ravikiran G Thirumalai
2003-05-07  6:16   ` Rusty Russell
2003-05-08  7:42     ` Ravikiran G Thirumalai
2003-05-08  7:47       ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2002-10-31 16:06 [patch] kmalloc_percpu Ravikiran G Thirumalai
2002-11-01  8:33 ` Rusty Russell
2002-11-05 16:00   ` Dipankar Sarma

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=20030505.203758.48517285.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=akpm@digeo.com \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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).