From: "Leonidas ." <leonidas137@gmail.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Gleb Natapov <gleb@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: How to check whether executing in atomic context?
Date: Thu, 15 Oct 2009 01:31:30 -0700 [thread overview]
Message-ID: <f22d86810910150131l303200bfq952f479b3fbff563@mail.gmail.com> (raw)
In-Reply-To: <f22d86810910141224i5f5d7725l9aa2b2262dc30ba4@mail.gmail.com>
On Wed, Oct 14, 2009 at 12:24 PM, Leonidas . <leonidas137@gmail.com> wrote:
> On Thu, Oct 15, 2009 at 12:45 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>> Leonidas . wrote:
>>> On Wed, Oct 14, 2009 at 11:09 PM, Stefan Richter
>>> <stefanr@s5r6.in-berlin.de> wrote:
>>>> let the caller of your routine tell it whether it's atomic context
>>>> or not.
>> [...]
>>> What makes it more complicated is this, the user might achieve the
>>> functionality via instrumenting his source code, i.e. something like
>>> using -finstrument flag of gcc. As per above inferences about
>>> in_atomic(), in case of instrumentation there is no choice other than
>>> providing all apis as atomic apis, this might not be the right thing
>>> to do under all circumstances. Especially, for my code since I do lot
>>> of allocations for book keeping.
>>>
>>> I am not aware of any Linux kernel module which can comply to this
>>> kind of use case, what would be the most optimal thing to do here?
>>
>> And preallocation is not feasible either?
>> --
>> Stefan Richter
>> -=====-==--= =-=- -===-
>> http://arcgraph.de/sr/
>>
>
> Yes, I preallocate a buffer at module init time. But assume that, I am
> profiling kmalloc(),
> and number of kmallocs() done over time increases rapidly, I need to allocate
> on demand as well depending on the load. (Actually, I am not profiling kmalloc,
> it just makes a good example in this case). Currently, I preallocate a
> large buffer
> and as I reach the threshold, I try to grab small buffers as needed.
> Obvious solution
> here would be to grab a larger buffer, the only issue here would be it
> might be just wasteful.
>
> So, knowing the running context and allocating sounded like a better idea to me.
>
> -Leo.
>
>Or deferring work to a kernel thread.
You mean, have a kernel thread periodically check the memory
requirements and do allocations in
kernel thread context? So basically, insuring that all the allocations
are done outside atomic context
i.e. either preallocate or use kernel thread.
-Leo.
prev parent reply other threads:[~2009-10-15 8:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-14 6:36 Leonidas .
2009-10-14 9:21 ` Leonidas .
2009-10-14 9:34 ` Leonidas .
2009-10-14 10:13 ` Gleb Natapov
2009-10-14 10:24 ` Leonidas .
2009-10-14 17:39 ` Stefan Richter
2009-10-14 19:11 ` Leonidas .
2009-10-14 19:15 ` Stefan Richter
2009-10-14 19:22 ` Samuel Thibault
2009-10-14 19:24 ` Leonidas .
2009-10-15 8:31 ` Leonidas . [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=f22d86810910150131l303200bfq952f479b3fbff563@mail.gmail.com \
--to=leonidas137@gmail.com \
--cc=gleb@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
/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®