On 4/12/07, Ken Chen <[EMAIL PROTECTED]> wrote:
On 4/12/07, Jeff Moyer <[EMAIL PROTECTED]> wrote:
> I didn't see any response to Zach's request for code that actually
> tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since last night. After
On 4/12/07, Jeff Moyer <[EMAIL PROTECTED]> wrote:
I didn't see any response to Zach's request for code that actually
tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since last night. After 20+
hours of stress run with fio and aio-stress, now
On Thu, Apr 12, 2007 at 10:31:31AM -0400, Benjamin LaHaise wrote:
> On Thu, Apr 12, 2007 at 12:50:39AM -0700, Ken Chen wrote:
> > I ran through the autotest (with bug fix in the test code). It passes
> > the regression tests. I made the following change since last rev:
>
> By removing the
On Thu, Apr 12, 2007 at 12:50:39AM -0700, Ken Chen wrote:
> I ran through the autotest (with bug fix in the test code). It passes
> the regression tests. I made the following change since last rev:
By removing the spinlock around ring insertion, you've made it possible
for two events being
==> On Thu, 12 Apr 2007 00:29:28 -0700, "Ken Chen" <[EMAIL PROTECTED]> said:
Ken> On 4/11/07, Ken Chen <[EMAIL PROTECTED]> wrote:
Ken> > On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
Ken> > > First, I'll NAK this and all AIO patches until the patch
Ken> description > > says that it's been run
On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
cd /usr/local
svn checkout
On 4/11/07, Ken Chen <[EMAIL PROTECTED]> wrote:
On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
> First, I'll NAK this and all AIO patches until the patch description
> says that it's been run through the regression tests that we've started
> collecting in autotest. They're trivial to run,
On 4/11/07, Ken Chen [EMAIL PROTECTED] wrote:
On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never
On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
cd /usr/local
svn checkout
== On Thu, 12 Apr 2007 00:29:28 -0700, Ken Chen [EMAIL PROTECTED] said:
Ken On 4/11/07, Ken Chen [EMAIL PROTECTED] wrote:
Ken On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
Ken First, I'll NAK this and all AIO patches until the patch
Ken description says that it's been run through the
On Thu, Apr 12, 2007 at 12:50:39AM -0700, Ken Chen wrote:
I ran through the autotest (with bug fix in the test code). It passes
the regression tests. I made the following change since last rev:
By removing the spinlock around ring insertion, you've made it possible
for two events being
On Thu, Apr 12, 2007 at 10:31:31AM -0400, Benjamin LaHaise wrote:
On Thu, Apr 12, 2007 at 12:50:39AM -0700, Ken Chen wrote:
I ran through the autotest (with bug fix in the test code). It passes
the regression tests. I made the following change since last rev:
By removing the spinlock
On 4/12/07, Jeff Moyer [EMAIL PROTECTED] wrote:
I didn't see any response to Zach's request for code that actually
tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since last night. After 20+
hours of stress run with fio and aio-stress, now
On 4/12/07, Ken Chen [EMAIL PROTECTED] wrote:
On 4/12/07, Jeff Moyer [EMAIL PROTECTED] wrote:
I didn't see any response to Zach's request for code that actually
tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since last night. After 20+
On Wed, Apr 11, 2007 at 12:52:56PM -0700, Zach Brown wrote:
> I'm worried that virtual aliasing spells doom for the current
> home-brewed serialization that fs/aio.c is doing with the shared ring
> head/tail accesses. Am I worrying about nothing here?
Adding a flush_dcache_page() should fix
> > I kept on getting requests from application developers who want that
> > feature. My initial patch was dated back May 2004.
>
> The right way to do it involves synchronization between the kernel side
> io_getevents() and the userspace code pulling events out of the ring.
> Alan Cox
On Wed, Apr 11, 2007 at 12:28:26PM -0700, Ken Chen wrote:
> >I have mixed feelings. I think the userspace getevents support was
> >poorly designed and the simple fact that we've gone this long without it
> >says just how desperately the feature isn't needed.
>
> I kept on getting requests from
> >I have mixed feelings. I think the userspace getevents support was
> >poorly designed and the simple fact that we've gone this long without it
> >says just how desperately the feature isn't needed.
>
> I kept on getting requests from application developers who want that
> feature. My initial
> Ken uses the other (superior!) way of implementing ringbuffers: the head
> and tail pointers (the naming of which AIO appears to have reversed) are
> not constrained to the ringsize - they are simply allowed to wrap through
> 0xfff.
A-ha! That sure sounds great.
I'd be happy to see the
On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
OK. I will run those regression tests.
On Wed, 11 Apr 2007 11:00:38 -0700
Zach Brown <[EMAIL PROTECTED]> wrote:
> > - /* Compensate for the ring buffer's head/tail overlap entry */
> > - nr_events += 2; /* 1 is required, 2 for good luck */
> > + /* round nr_event to next power of 2 */
> > + nr_events =
On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
> Sorry I wasn't thorough enough. And partially because I was worried
> about changing structure type for user space facing struct aio_ring.
> Now that I looked through all arches, it looks safe as all arch's
> atomic_t has the same size as int.
> Sorry I wasn't thorough enough. And partially because I was worried
> about changing structure type for user space facing struct aio_ring.
> Now that I looked through all arches, it looks safe as all arch's
> atomic_t has the same size as int.
> Here is the updated patch.
> @@ -144,7 +144,7
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
cd /usr/local
svn checkout svn://test.kernel.org/autotest/trunk/client autotest
cd autotest
On 4/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Tue, 10 Apr 2007 16:53:53 -0700 (PDT) [EMAIL PROTECTED] (Ken Chen) wrote:
> + } while (head != cmpxchg(>head, head, head + 1));
A hasty grep indicates that only 14 out of 23 architectures implement
cmpxchg().
Sorry I wasn't thorough
On 4/10/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 10 Apr 2007 16:53:53 -0700 (PDT) [EMAIL PROTECTED] (Ken Chen) wrote:
+ } while (head != cmpxchg(ring-head, head, head + 1));
A hasty grep indicates that only 14 out of 23 architectures implement
cmpxchg().
Sorry I wasn't
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
cd /usr/local
svn checkout svn://test.kernel.org/autotest/trunk/client autotest
cd autotest
Sorry I wasn't thorough enough. And partially because I was worried
about changing structure type for user space facing struct aio_ring.
Now that I looked through all arches, it looks safe as all arch's
atomic_t has the same size as int.
Here is the updated patch.
@@ -144,7 +144,7 @@
On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
Sorry I wasn't thorough enough. And partially because I was worried
about changing structure type for user space facing struct aio_ring.
Now that I looked through all arches, it looks safe as all arch's
atomic_t has the same size as int.
On Wed, 11 Apr 2007 11:00:38 -0700
Zach Brown [EMAIL PROTECTED] wrote:
- /* Compensate for the ring buffer's head/tail overlap entry */
- nr_events += 2; /* 1 is required, 2 for good luck */
+ /* round nr_event to next power of 2 */
+ nr_events = roundup_pow_of_two(nr_events);
On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
OK. I will run those regression tests.
Ken uses the other (superior!) way of implementing ringbuffers: the head
and tail pointers (the naming of which AIO appears to have reversed) are
not constrained to the ringsize - they are simply allowed to wrap through
0xfff.
A-ha! That sure sounds great.
I'd be happy to see the kernel
On Wed, Apr 11, 2007 at 12:28:26PM -0700, Ken Chen wrote:
I have mixed feelings. I think the userspace getevents support was
poorly designed and the simple fact that we've gone this long without it
says just how desperately the feature isn't needed.
I kept on getting requests from
I have mixed feelings. I think the userspace getevents support was
poorly designed and the simple fact that we've gone this long without it
says just how desperately the feature isn't needed.
I kept on getting requests from application developers who want that
feature. My initial patch
I kept on getting requests from application developers who want that
feature. My initial patch was dated back May 2004.
The right way to do it involves synchronization between the kernel side
io_getevents() and the userspace code pulling events out of the ring.
Alan Cox suggested
On Wed, Apr 11, 2007 at 12:52:56PM -0700, Zach Brown wrote:
I'm worried that virtual aliasing spells doom for the current
home-brewed serialization that fs/aio.c is doing with the shared ring
head/tail accesses. Am I worrying about nothing here?
Adding a flush_dcache_page() should fix that,
On Tue, 10 Apr 2007 16:53:53 -0700 (PDT) [EMAIL PROTECTED] (Ken Chen) wrote:
> + } while (head != cmpxchg(>head, head, head + 1));
A hasty grep indicates that only 14 out of 23 architectures implement
cmpxchg().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Resurrect an old patch that uses atomic operation to update ring buffer
index on AIO event queue. This work allows futher application/libaio
optimization to run fast path io_getevents in user space.
I've also added one more change on top of old implementation that rounds
ring buffer size to
Resurrect an old patch that uses atomic operation to update ring buffer
index on AIO event queue. This work allows futher application/libaio
optimization to run fast path io_getevents in user space.
I've also added one more change on top of old implementation that rounds
ring buffer size to
On Tue, 10 Apr 2007 16:53:53 -0700 (PDT) [EMAIL PROTECTED] (Ken Chen) wrote:
+ } while (head != cmpxchg(ring-head, head, head + 1));
A hasty grep indicates that only 14 out of 23 architectures implement
cmpxchg().
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
40 matches
Mail list logo
