From: Brent Baccala <cosine@freesoft.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: async I/O seems to be blocking on 2.6.15
Date: Fri, 3 Nov 2006 12:09:50 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.64.0611031204110.20496@debian.freesoft.org> (raw)
In-Reply-To: <20061103160212.GK13555@kernel.dk>
On Fri, 3 Nov 2006, Jens Axboe wrote:
> On Fri, Nov 03 2006, Brent Baccala wrote:
>>
>> ...
>>
>> The enqueues still take a noticable amount of time, though, just a lot
>> less than before. They average 1 second total. That's 100 one-MB
>> reads, broken down into 128 KB blocks, I suppose, for a total of 800
>> low-level reads. Setting nr_requests higher (2048) doesn't seem to do
>> any more good.
>>
>> I can see that you've put me on the right track, but I am still
>> puzzling... any idea what the remaining second is being used for?
>
> Try to time it (visual output of the app is not very telling, and it's
> buffered) and then apply some profiling.
>
Yeah, I did time it. I bracketed the enqueues with calls to
gettimeofday(). It takes them about a second to run, and I made sure
that the fprintfs were outside the timing checks. Here's the actual code:
fprintf(stderr, "Enqueues starting\n");
gettimeofday(&tv1, NULL);
for (i=0; i<NUMAIOS; i++) {
memset(&iocb[i], 0, sizeof(struct iocb));
iocb[i].aio_lio_opcode = IOCB_CMD_PREAD;
iocb[i].aio_fildes = fd;
iocb[i].aio_buf = (unsigned long) buffer[i];
iocb[i].aio_nbytes = BUFFER_BYTES;
iocb[i].aio_offset = BUFFER_BYTES * i;
/* aiocb[i].aio_offset = 0; */
iocbp[0] = &iocb[i];
if (io_submit(aio_default_context, 1, iocbp) != 1) {
perror("");
fprintf(stderr, "Can't enqueue aio_read %d\n", i);
}
}
gettimeofday(&tv2, NULL);
subtract_timeval(&tv2, &tv1);
sprint_timeval(strbuf, &tv2);
fprintf(stderr, "Enqueues complete in %s\n", strbuf);
And the output:
baccala@debian ~/src/endgame$ time ./testaio
Enqueues starting
Enqueues complete in 1.187s
real 0m5.335s
user 0m0.001s
sys 0m0.760s
baccala@debian ~/src/endgame$
What kind of profiling did you have in mind? Kernel profiling? As
you can see, its user time is basically nil.
-bwb
Brent Baccala
cosine@freesoft.org
next prev parent reply other threads:[~2006-11-03 17:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-03 8:23 Brent Baccala
2006-11-03 12:20 ` Jens Axboe
2006-11-03 15:58 ` Brent Baccala
2006-11-03 16:02 ` Jens Axboe
2006-11-03 17:09 ` Brent Baccala [this message]
2006-11-03 17:30 ` Brent Baccala
2006-11-05 12:15 ` Jens Axboe
2006-11-06 6:42 ` Brent Baccala
2006-11-06 10:43 ` Jens Axboe
2006-11-06 15:52 ` Phillip Susi
2006-11-06 16:02 ` Jens Axboe
2006-11-06 17:04 ` Phillip Susi
2006-11-06 17:10 ` Jens Axboe
2006-11-06 21:22 ` Chen, Kenneth W
2006-11-07 7:26 ` Jens Axboe
2006-11-07 21:02 ` Bill Davidsen
2006-11-10 9:24 ` Jens Axboe
2006-11-07 0:03 Brent Baccala
2006-11-07 0:24 ` Chen, Kenneth W
2006-11-07 7:29 ` Jens Axboe
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=Pine.LNX.4.64.0611031204110.20496@debian.freesoft.org \
--to=cosine@freesoft.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.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 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®