From: kai@gnukai.com (Kai Meyer)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Generic I/O
Date: Tue, 15 Nov 2011 11:40:26 -0700 [thread overview]
Message-ID: <4EC2B21A.4070005@gnukai.com> (raw)
In-Reply-To: <20111115181321.GA2219@grml>
On 11/15/2011 11:13 AM, michi1 at michaelblizek.twilightparadox.com wrote:
> Hi!
>
> On 12:15 Mon 14 Nov , Kai Meyer wrote:
> ...
>
>> My
>> caller function has an atomic_t value that I set equal to the number of
>> bios I want to submit. Then I pass a pointer to that atomic_t around to
>> each of the bios which decrement it in the endio function for that bio.
>>
>> Then the caller does this:
>> while(atomic_read(numbios)> 0)
>> msleep(1);
>>
>> I'm finding the msleep(1) is a really really really long time,
>> relatively. It seems to work ok if I just have an empty loop, but it
>> also seems to me like I'm re-inventing a wheel here.
> ...
>
> You might want to take a look at wait queues (the kernel equivalent to pthread
> "condidions"). Basically you instead of calling msleep(), you call
> wait_event(). In the function which decrements numbios, you check whether it
> is 0 and if so call wake_up().
>
> -Michi
That sounds very promising. When I read up on wait_event here:
lxr.linux.no/#linux+v2.6.32/include/linux/wait.h#L191
It sounds like it's basically doing the same thing. I would call it like so:
wait_event(wq, atomic_read(numbios) == 0);
To make sure I understand, this seems very much like what I'm doing,
except I'm being woken up every time a bio finishes instead of being
woken up once every millisecond. That is, I'm assuming I would use the
same work queue for all my bios.
During my testing, when I do a lot of disk I/O, I may potentially have
hundreds of threads waiting on anywhere between 1 and 32 bios. Help me
understand the sort of impact you think I might see between having
hundreds waiting for a millisecond, and having hundreds get woken up
each time a bio completes. It seems like it would be very helpful in low
I/O scenarios, especially when there are fast disks involved. I'm
concerned that during heavy I/O loads, I'll be doing a lot of
atomic_reads, and I have the impression that atomic_read isn't the
cheapest operation.
-Kai Meyer
next prev parent reply other threads:[~2011-11-15 18:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 19:15 Generic I/O Kai Meyer
2011-11-15 18:13 ` michi1 at michaelblizek.twilightparadox.com
2011-11-15 18:40 ` Kai Meyer [this message]
2011-11-15 19:12 ` michi1 at michaelblizek.twilightparadox.com
-- strict thread matches above, loose matches on Subject: below --
2011-10-31 16:24 generic I/O Kai Meyer
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=4EC2B21A.4070005@gnukai.com \
--to=kai@gnukai.com \
--cc=kernelnewbies@lists.kernelnewbies.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.