From: Timur Tabi <timur.tabi@ammasso.com>
To: Denis Vlasenko <vda@ilport.com.ua>
Cc: rostedt@goodmis.org, Arjan van de Ven <arjan@infradead.org>,
Jens Axboe <axboe@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: kmalloc without GFP_xxx?
Date: Wed, 29 Jun 2005 11:48:01 -0500 [thread overview]
Message-ID: <42C2D0C1.4030500@ammasso.com> (raw)
In-Reply-To: <200506291714.32990.vda@ilport.com.ua>
Denis Vlasenko wrote:
> This is why I always use _irqsave. Less error prone.
No, it's just bad programming. How hard can it be to see which spinlocks are being used
by your ISR and which ones aren't? Only the ones that your ISR touches should have
_irqsave. It's really quite simple.
> This is more or less what I meant. Why think about each kmalloc and when you
> eventually did get it right: "Aha, we _sometimes_ get called from spinlocked code,
> GFP_ATOMIC then" - you still do atomic alloc even if cases when you
> were _not_ called from locked code! Thus you needed to think longer and got
> code which is worse.
So you're saying that you're the kind of programmer who makes more mistakes the longer you
think about something?????
Using GFP_ATOMIC increases the probability that you won't be able to allocate the memory
you need, and it also increases the probability that some other module that really needs
GFP_ATOMIC will also be unable to allocate the memory it needs. Please tell me, how is
this considered good programming?
--
Timur Tabi
Staff Software Engineer
timur.tabi@ammasso.com
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
next prev parent reply other threads:[~2005-06-29 16:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-29 11:02 kmalloc without GFP_xxx? Denis Vlasenko
2005-06-29 11:15 ` Jens Axboe
2005-06-29 11:18 ` Denis Vlasenko
2005-06-29 11:25 ` Jens Axboe
2005-06-29 11:15 ` Arjan van de Ven
2005-06-29 11:20 ` Denis Vlasenko
2005-06-29 11:37 ` Arjan van de Ven
2005-06-29 13:44 ` Steven Rostedt
2005-06-29 14:14 ` Denis Vlasenko
2005-06-29 14:23 ` Jörn Engel
2005-06-29 14:53 ` Steven Rostedt
2005-06-29 15:10 ` Jörn Engel
2005-06-29 15:48 ` Steven Rostedt
2005-06-29 15:54 ` Jörn Engel
2005-06-29 16:04 ` Steven Rostedt
2005-06-29 15:12 ` Oliver Neukum
2005-06-29 16:48 ` Timur Tabi [this message]
2005-06-29 17:22 ` Steven Rostedt
2005-06-29 17:43 ` Richard B. Johnson
2005-06-29 18:07 ` Steven Rostedt
2005-06-30 7:52 ` Denis Vlasenko
2005-06-30 8:05 ` Steven Rostedt
2005-06-30 1:02 ` Benjamin Herrenschmidt
2005-06-30 6:02 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2005-06-29 20:28 Manfred Spraul
2005-06-29 20:44 Manfred Spraul
2005-06-30 5:57 ` Steven Rostedt
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=42C2D0C1.4030500@ammasso.com \
--to=timur.tabi@ammasso.com \
--cc=arjan@infradead.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=vda@ilport.com.ua \
/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