Date: Mon, 05 May 2003 20:37:58 -0700 (PDT)
Message-Id: <20030505.203758.48517285.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
From: "David S. Miller" <davem@redhat.com>
In-Reply-To: <20030505212816.7cb0ec49.akpm@digeo.com>
References: <1052187119.983.5.camel@rth.ninka.net>
	<20030506040856.8B3712C36E@lists.samba.org>
	<20030505212816.7cb0ec49.akpm@digeo.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1366
Lines: 34

   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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/