From: "Drokin, Oleg" <oleg.drokin@intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>,
"<devel@driverdev.osuosl.org>" <devel@driverdev.osuosl.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
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@ml01.01.org>" <HPDD-discuss@ml01.01.org>
Subject: Re: [PATCH] staging: lustre: llite: Use kzalloc and rewrite null tests
Date: Fri, 19 Sep 2014 13:27:49 +0000 [thread overview]
Message-ID: <775505CF-0184-47D7-BF7A-47A5F1382E89@intel.com> (raw)
In-Reply-To: <20140919091151.GQ17875@mwanda>
On Sep 19, 2014, at 5:11 AM, Dan Carpenter wrote:
> On Fri, Sep 19, 2014 at 02:57:03AM +0000, Drokin, Oleg wrote:
>> 4. Sometimes we need large allocations. general kmalloc is less
>> reliable as system lives on and memory fragmentation worsens. So we
>> have this "allocations over 2-4 pages get switched to vmalloc" logic,
>> if there's a way to do that automatically - that would be great.
>
> Julia's patch only changes OBD_ALLOC() functions and those are always
> kmalloc so that's not an issue here.
That's true. Though it would be strange to convert just a subset of those
allocating macros, and the solution for the OBD_ALLOC_LARGE would
also be needed.
>
> The OBD_ALLOC_LARGE() macro is vmalloc() or kmalloc() if the size is
> small enough. We don't really want to choose between kmalloc and
> vmalloc automatically. My instinct is that we should change all the
> OBD_ALLOC_LARGE() to vmalloc() and trust it to allocate them in the most
> sane way possible. But I haven't really looked very closely.
We found that vmalloc (at least with larger allocs, I did not look into details)
has quite a big penalty with some internal lock that creates big contention at
production loads.
So of course the desire is there to reduce our allocations when we can.
(additionally on 32 bit arches there's always this issue of vmalloc region
possibly not being large enough to allocate everything we might want whenever
we see a way for that).
Thanks.
Bye,
Oleg
prev parent reply other threads:[~2014-09-19 13:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 20:24 [PATCH] " Julia Lawall
2014-09-18 20:24 ` [PATCH] staging: lustre: llite: " Julia Lawall
2014-09-18 23:43 ` Dan Carpenter
2014-09-19 2:57 ` Drokin, Oleg
2014-09-19 3:04 ` [HPDD-discuss] " Drokin, Oleg
2014-09-19 4:45 ` Julia Lawall
2014-09-19 13:36 ` Drokin, Oleg
2014-09-19 13:50 ` Julia Lawall
2014-09-19 9:11 ` Dan Carpenter
2014-09-19 13:27 ` Drokin, Oleg [this message]
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=775505CF-0184-47D7-BF7A-47A5F1382E89@intel.com \
--to=oleg.drokin@intel.com \
--cc=HPDD-discuss@ml01.01.org \
--cc=Julia.Lawall@lip6.fr \
--cc=andreas.dilger@intel.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®