From: Ric Wheeler <rwheeler@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Josef Bacik <jbacik@redhat.com>,
linux-fsdevel@vger.kernel.org,
Chris Mason <chris.mason@oracle.com>,
linux-kernel@vger.kernel.org
Subject: high resolution timers, scheduling & sleep granularity
Date: Fri, 01 Aug 2008 08:05:37 -0400 [thread overview]
Message-ID: <4892FC11.4020105@redhat.com> (raw)
Hi Thomas & Ingo,
Josef has been working on some patches to try and get ext3/4 to
dynamically detect the latency of a storage device and use that base
latency to tune the amount of time we sleep waiting for others to join
in a transaction. The logic in question lives in jbd/transaction.c
(transaction_stop).
The code was originally developed to try and allow multiple threads to
join in a big, slow transaction. For example, transacations that write
to a slow ATA or S-ATA drive take in the neighborhood of 10 to 20 ms.
Faster devices, for example a disk array, can complete the transaction
in 1.3 ms. Even higher speed SSD devices boast of a latency of 0.1ms,
not to mention RAM disks ;-)
The current logic makes us wait way too long, especially with a 250HZ
kernel since we sleep many times longer than it takes to complete the IO ;-)
Do either of you have any thoughts on how to get a better, fine grained
sleep capability that we could use that would allow us to sleep in
sub-jiffie chunks?
Regards,
Ric
WARNING: multiple messages have this Message-ID (diff)
From: Ric Wheeler <rwheeler@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Josef Bacik <jbacik@redhat.com>,
linux-fsdevel@vger.kernel.org,
Chris Mason <chris.mason@oracle.com>,
linux-kernel@v
Subject: high resolution timers, scheduling & sleep granularity
Date: Fri, 01 Aug 2008 08:05:37 -0400 [thread overview]
Message-ID: <4892FC11.4020105@redhat.com> (raw)
Hi Thomas & Ingo,
Josef has been working on some patches to try and get ext3/4 to
dynamically detect the latency of a storage device and use that base
latency to tune the amount of time we sleep waiting for others to join
in a transaction. The logic in question lives in jbd/transaction.c
(transaction_stop).
The code was originally developed to try and allow multiple threads to
join in a big, slow transaction. For example, transacations that write
to a slow ATA or S-ATA drive take in the neighborhood of 10 to 20 ms.
Faster devices, for example a disk array, can complete the transaction
in 1.3 ms. Even higher speed SSD devices boast of a latency of 0.1ms,
not to mention RAM disks ;-)
The current logic makes us wait way too long, especially with a 250HZ
kernel since we sleep many times longer than it takes to complete the IO ;-)
Do either of you have any thoughts on how to get a better, fine grained
sleep capability that we could use that would allow us to sleep in
sub-jiffie chunks?
Regards,
Ric
next reply other threads:[~2008-08-01 12:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-01 12:05 Ric Wheeler [this message]
2008-08-01 12:05 ` high resolution timers, scheduling & sleep granularity Ric Wheeler
2008-08-01 13:25 ` Josef Bacik
2008-08-01 13:57 ` Ric Wheeler
2008-08-01 13:55 ` Josef Bacik
2008-08-01 14:50 ` Peter Zijlstra
2008-08-01 14:34 ` Josef Bacik
2008-08-01 15:03 ` Ric Wheeler
2008-08-01 18:16 ` Andreas Dilger
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=4892FC11.4020105@redhat.com \
--to=rwheeler@redhat.com \
--cc=chris.mason@oracle.com \
--cc=jbacik@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.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 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.