linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
To: cmm@us.ibm.com
Cc: Christoph Hellwig <hch@infradead.org>,
	Badari Pulavarty <pbadari@us.ibm.com>,
	Christoph Lameter <clameter@sgi.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	ext4 development <linux-ext4@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] JBD slab cleanups
Date: Tue, 18 Sep 2007 13:04:50 -0500	[thread overview]
Message-ID: <1190138690.6528.23.camel@norville.austin.ibm.com> (raw)
In-Reply-To: <1190133347.3819.6.camel@localhost.localdomain>

On Tue, 2007-09-18 at 09:35 -0700, Mingming Cao wrote:
> On Tue, 2007-09-18 at 10:04 +0100, Christoph Hellwig wrote:
> > On Mon, Sep 17, 2007 at 03:57:31PM -0700, Mingming Cao wrote:
> > > Here is the incremental small cleanup patch. 
> > > 
> > > Remove kamlloc usages in jbd/jbd2 and consistently use jbd_kmalloc/jbd2_malloc.
> > 
> > Shouldn't we kill jbd_kmalloc instead?
> > 
> 
> It seems useful to me to keep jbd_kmalloc/jbd_free. They are central
> places to handle memory (de)allocation(<page size) via kmalloc/kfree, so
> in the future if we need to change memory allocation in jbd(e.g. not
> using kmalloc or using different flag), we don't need to touch every
> place in the jbd code calling jbd_kmalloc.

I disagree.  Why would jbd need to globally change the way it allocates
memory?  It currently uses kmalloc (and jbd_kmalloc) for allocating a
variety of structures.  Having to change one particular instance won't
necessarily mean we want to change all of them.  Adding unnecessary
wrappers only obfuscates the code making it harder to understand.  You
wouldn't want every subsystem to have it's own *_kmalloc() that took
different arguments.  Besides, there aren't that many calls to kmalloc
and kfree in the jbd code, so there wouldn't be much pain in changing
GFP flags or whatever, if it ever needed to be done.

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

  reply	other threads:[~2007-09-18 18:04 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070828190551.415127746@sgi.com>
     [not found] ` <20070828190735.292638294@sgi.com>
2007-08-30  0:11   ` [31/36] Large Blocksize: Core piece Mingming Cao
2007-08-30  0:12     ` Christoph Lameter
2007-08-30  0:47     ` [RFC 1/4] Large Blocksize support for Ext2/3/4 Mingming Cao
2007-08-30  0:59       ` Christoph Lameter
2007-09-01  0:01       ` Mingming Cao
2007-09-01  0:12       ` [RFC 1/2] JBD: slab management support for large block(>8k) Mingming Cao
2007-09-01 18:39         ` Christoph Hellwig
2007-09-02 11:40           ` Christoph Lameter
2007-09-02 15:28             ` Christoph Hellwig
2007-09-03  7:55               ` Christoph Lameter
2007-09-03 13:40                 ` Christoph Hellwig
2007-09-03 19:31                   ` Christoph Lameter
2007-09-03 19:33                     ` Christoph Hellwig
2007-09-14 18:53                       ` [PATCH] JBD slab cleanups Mingming Cao
2007-09-14 18:58                         ` Christoph Lameter
2007-09-17 19:29                         ` Mingming Cao
2007-09-17 19:34                           ` Christoph Hellwig
2007-09-17 22:01                           ` Badari Pulavarty
2007-09-17 22:57                             ` Mingming Cao
2007-09-18  9:04                               ` Christoph Hellwig
2007-09-18 16:35                                 ` Mingming Cao
2007-09-18 18:04                                   ` Dave Kleikamp [this message]
2007-09-19  1:00                                     ` Mingming Cao
2007-09-19  2:19                                       ` Andrew Morton
2007-09-19 19:15                                         ` Mingming Cao
2007-09-19 19:22                                           ` [PATCH] JBD: use GFP_NOFS in kmalloc Mingming Cao
2007-09-19 21:34                                             ` Andrew Morton
2007-09-19 21:55                                               ` Mingming Cao
2007-09-20  4:25                                             ` Andreas Dilger
2007-09-19 19:26                                           ` [PATCH] JBD slab cleanups Dave Kleikamp
2007-09-19 19:28                                             ` Dave Kleikamp
2007-09-19 20:47                                               ` Mingming Cao
2007-09-19 19:48                                           ` Andreas Dilger
2007-09-19 22:03                                             ` Mingming Cao
2007-09-01  0:12       ` [RFC 2/2] JBD: blocks reservation fix for large block support Mingming Cao
2007-08-30  0:47     ` [RFC 2/4]ext2: fix rec_len overflow with 64KB block size Mingming Cao
     [not found] ` <20070828190730.220393749@sgi.com>
2007-08-30  9:20   ` [11/36] Use page_cache_xxx in fs/buffer.c Dmitry Monakhov
2007-08-30 18:14     ` Christoph Lameter
2007-08-31  1:47       ` Christoph Lameter
2007-08-31  6:56         ` Jens Axboe
2007-08-31  7:03           ` Christoph Lameter
2007-08-31  7:11             ` Jens Axboe
2007-08-31  7:17               ` Christoph Lameter
2007-08-31  7:26                 ` Jens Axboe
2007-08-31  7:33                   ` Christoph Lameter
2007-08-31  7:43                     ` Jens Axboe
2007-08-31  7:52                       ` Christoph Lameter
2007-08-31  8:12                         ` Jens Axboe
2007-08-31 15:22                           ` Christoph Lameter
2007-08-31 16:35                             ` Jörn Engel
2007-08-31 19:00                             ` Jens Axboe
2007-08-31  8:36                         ` Dmitry Monakhov
2007-08-31 15:28                           ` Christoph Lameter
     [not found] ` <20070828192034.GA13883@lst.de>
     [not found]   ` <Pine.LNX.4.64.0708281254070.16473@schroedinger.engr.sgi.com>
2007-09-01  1:11     ` [00/36] Large Blocksize Support V6 Christoph Lameter
2007-09-01 19:17 ` Peter Zijlstra
2007-09-02 11:44   ` Christoph Lameter

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=1190138690.6528.23.camel@norville.austin.ibm.com \
    --to=shaggy@linux.vnet.ibm.com \
    --cc=clameter@sgi.com \
    --cc=cmm@us.ibm.com \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.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;
as well as URLs for NNTP newsgroup(s).