public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: "Simmons, James A." <simmonsja@ornl.gov>
To: 'Julia Lawall' <julia.lawall@lip6.fr>
Cc: Oleg Drokin <oleg.drokin@intel.com>,
	"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"HPDD-discuss@lists.01.org" <HPDD-discuss@ml01.01.org>
Subject: RE: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree
Date: Fri, 01 May 2015 20:18:56 +0000	[thread overview]
Message-ID: <524505df3433441494cf082a425f2ee7@EXCHCS32.ornl.gov> (raw)
In-Reply-To: <alpine.DEB.2.02.1505011945350.2092@localhost6.localdomain6>

>> >From: Julia Lawall <Julia.Lawall@lip6.fr>
>> >
>> >Replace OBD_ALLOC, OBD_ALLOC_WAIT, OBD_ALLOC_PTR, and OBD_ALLOC_PTR_WAIT by
>> >kalloc/kcalloc, and OBD_FREE and OBD_FREE_PTR by kfree.
>> 
>> Nak: James Simmons <jsimmons@infradead.org>
>> 
>> A simple replace will not work. The OBD_ALLOC and OBD_FREE functions allocate memory
>> anywhere from one page to 4MB in size. You can't use kmalloc for the 4MB allocations.
>> Currently lustre uses  a 4 page water mark to determine if we allocate using vmalloc. Even
>> using kmalloc for 4 pages has shown high failure rates on some systems. It gets even more
>> messy with 64K page systems like ppc64 boxes. Now I'm not suggesting to port the larger
>> allocations to vmalloc either since issues have been founded with using vmalloc. For example
>> when using large stripe count files the MDS rpc generated crosses the 4 page line and vmalloc
>> is used. Using vmalloc caused a global spinlock to be taken which causes meta data operations
>> to serialized on the MDS servers.
>
>It's not the LARGE functions that do the switching?  For example OBD_ALLOC 
>ends up at  __OBD_MALLOC_VERBOSE, which as far as I can see calls kmalloc 
>(with __GFP_ZERO, and hance the use of kzalloc).

Yes the LARGE functions do the switching. I was expecting also patches to remove the 
OBD_ALLOC_LARGE functions as well which is not the case here.  I do have one question still. The
macro __OBD_MALLOC_VERBOSE allowed the ability to simulate memory allocation failures at
a certain percentage rate. Does something exist in the kernel to duplicate that functionality?
Once these macros are gone we lose the ability to simulate high memory allocation failures.



  parent reply	other threads:[~2015-05-01 20:18 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01 15:51 [PATCH 0/11] Use kzalloc and kfree Julia Lawall
2015-05-01 15:51 ` [PATCH 11/11] staging: lustre: ptlrpc: " Julia Lawall
2015-05-01 15:51 ` [PATCH 10/11] staging: lustre: osc: " Julia Lawall
2015-05-01 15:51 ` [PATCH 9/11] staging: lustre: obdecho: " Julia Lawall
2015-05-01 15:51 ` [PATCH 8/11] staging: lustre: obdclass: " Julia Lawall
2015-05-01 18:30   ` walter harms
2015-05-01 18:42     ` Julia Lawall
2015-05-01 15:51 ` [PATCH 7/11] staging: lustre: mgc: " Julia Lawall
2015-05-01 15:51 ` [PATCH 6/11] staging: lustre: mdc: " Julia Lawall
2015-05-01 15:51 ` [PATCH 5/11] staging: lustre: lmv: " Julia Lawall
2015-05-01 15:51 ` [PATCH 4/11] staging: lustre: ldlm: " Julia Lawall
2015-05-01 15:51 ` [PATCH 3/11] staging: lustre: lclient: " Julia Lawall
2015-05-01 15:51 ` [PATCH 2/11] Staging: lustre: fld: " Julia Lawall
2015-05-01 17:38   ` [HPDD-discuss] " Simmons, James A.
2015-05-01 17:48     ` Julia Lawall
2015-05-01 18:49       ` Drokin, Oleg
2015-05-01 20:18       ` Simmons, James A. [this message]
2015-05-01 20:47         ` Greg Kroah-Hartman
2015-05-01 22:57           ` Simmons, James A.
2015-05-01 20:49         ` Drokin, Oleg
2015-05-01 22:59           ` Simmons, James A.
2015-05-01 18:05     ` Greg Kroah-Hartman
2015-05-01 20:02     ` Dan Carpenter
2015-05-01 20:12       ` Drokin, Oleg
2015-05-01 20:36       ` Simmons, James A.
2015-05-01 20:49         ` Greg Kroah-Hartman
2015-05-01 20:52           ` Drokin, Oleg
2015-05-01 20:58             ` Greg Kroah-Hartman
2015-05-01 21:13               ` Drokin, Oleg
2015-05-02  6:02                 ` Julia Lawall
2015-05-02  8:14                 ` Dan Carpenter
2015-05-02  9:05                   ` Julia Lawall
2015-05-03  3:12                   ` Drokin, Oleg
2015-05-02  1:18     ` Simmons, James A.
2015-05-02  8:26     ` 'Greg Kroah-Hartman'
2015-05-02 17:17     ` Drokin, Oleg
2015-05-02 17:33     ` Greg Kroah-Hartman
2015-05-04 14:07     ` Simmons, James A.
2015-05-04 15:01     ` Dan Carpenter
2015-05-04 21:26     ` 'Greg Kroah-Hartman'
2015-05-01 15:51 ` [PATCH 1/11] staging: lustre: fid: " Julia Lawall
2015-05-03 18:17 ` [PATCH 0/11] " Greg Kroah-Hartman
2015-05-03 18:39   ` Julia Lawall

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=524505df3433441494cf082a425f2ee7@EXCHCS32.ornl.gov \
    --to=simmonsja@ornl.gov \
    --cc=HPDD-discuss@ml01.01.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=julia.lawall@lip6.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg.drokin@intel.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