Tejun Heo wrote:
Mark Lord wrote:
Support for IDENTIFY PACKET DEVICE would be nice too.
It already does that, using HDIO_DRIVE_CMD to retrieve it
in the same way as for regular IDENTIFY DEVICE commands.
Hmmm... My hdparm doesn't seem to do that.
Sure it does.
Try "strace hdparm -I
Mark Lord wrote:
> Tejun Heo wrote:
>>
>> OT but care to make -i and -I work equivalently? Such that -i reports
>> more detailed info and user can dump stored id block.
>
> hdparm -I works just fine now.
No objection there.
> hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
>
Tejun Heo wrote:
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block.
hdparm -I works just fine now.
hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
to retrieve the "boot time" copy of the identify
On Jan 2 2007 10:01, Mark Lord wrote:
> Jens Axboe wrote:
>>
>> > But surely one of (not sure which) sync+async or async+sync may also
>> > be okay?
>> > Or would it?
>>
>> Async merge to sync request should be ok. But I wonder what happens with
>> hdparm, since it seems to trigger one of these
Mark Lord wrote:
> The code (written 10 years ago) isn't the best in the world,
> and will be redone entirely for hdparm-7.0 this year.
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block. Support for
IDENTIFY PACKET DEVICE
On Tue, Jan 02 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >
> >>I did have to massage the second patch to get it to apply cleanly
> >>after the first patch. You may want to regenerate it against -rc3.
> >
> >Hmm odd, I thought I did. Will double check.
>
> Ahh.. I get it now.
>
> I tried to
Jens Axboe wrote:
I did have to massage the second patch to get it to apply cleanly
after the first patch. You may want to regenerate it against -rc3.
Hmm odd, I thought I did. Will double check.
Ahh.. I get it now.
I tried to apply the second patch *on top* of the first patch,
whereas
On Tue, Jan 02 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Tue, Jan 02 2007, Jens Axboe wrote:
> >>On Tue, Jan 02 2007, Rene Herman wrote:
> >>>Jens Axboe wrote:
> >>>
> On Mon, Jan 01 2007, Andrew Morton wrote:
> >The patch would appear to need this fix:
> >
> >---
Jens Axboe wrote:
On Tue, Jan 02 2007, Jens Axboe wrote:
On Tue, Jan 02 2007, Rene Herman wrote:
Jens Axboe wrote:
On Mon, Jan 01 2007, Andrew Morton wrote:
The patch would appear to need this fix:
--- a/block/cfq-iosched.c~a
+++ a/block/cfq-iosched.c
@@ -592,7 +592,7 @@ static int
Jens Axboe wrote:
But surely one of (not sure which) sync+async or async+sync may also be
okay?
Or would it?
Async merge to sync request should be ok. But I wonder what happens with
hdparm, since it seems to trigger one of these tests. Very puzzling.
I'll dive in and take a look.
The code
On Tue, Jan 02 2007, Jens Axboe wrote:
> On Tue, Jan 02 2007, Rene Herman wrote:
> > Jens Axboe wrote:
> >
> > >On Mon, Jan 01 2007, Andrew Morton wrote:
> >
> > >>The patch would appear to need this fix:
> > >>
> > >>--- a/block/cfq-iosched.c~a
> > >>+++ a/block/cfq-iosched.c
> > >>@@ -592,7
On Tue, Jan 02 2007, Rene Herman wrote:
> Jens Axboe wrote:
>
> >On Mon, Jan 01 2007, Andrew Morton wrote:
>
> >>The patch would appear to need this fix:
> >>
> >>--- a/block/cfq-iosched.c~a
> >>+++ a/block/cfq-iosched.c
> >>@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
> >>if
Jens Axboe wrote:
On Mon, Jan 01 2007, Andrew Morton wrote:
The patch would appear to need this fix:
--- a/block/cfq-iosched.c~a
+++ a/block/cfq-iosched.c
@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
if (cfqq == RQ_CFQQ(rq))
return 1;
- return 1;
+
On Mon, Jan 01 2007, Andrew Morton wrote:
> On Mon, 01 Jan 2007 23:46:58 +0100
> Rene Herman <[EMAIL PROTECTED]> wrote:
>
> > > Everything seems fine in the dmesg. Performance degradation is
> > > probably some other issue in -rc kernel. I'm suspecting recently
> > > fixed block layer bug. If
On Mon, Jan 01 2007, Mark Lord wrote:
> Rene Herman wrote:
> >Tejun Heo wrote:
> >
> >>Everything seems fine in the dmesg. Performance degradation is
> >>probably some other issue in -rc kernel. I'm suspecting recently
> >>fixed block layer bug. If it's still the same in the next -rc,
>
On Mon, Jan 01 2007, Mark Lord wrote:
Rene Herman wrote:
Tejun Heo wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the same in the next -rc,
please report.
In
On Mon, Jan 01 2007, Andrew Morton wrote:
On Mon, 01 Jan 2007 23:46:58 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the
Jens Axboe wrote:
On Mon, Jan 01 2007, Andrew Morton wrote:
The patch would appear to need this fix:
--- a/block/cfq-iosched.c~a
+++ a/block/cfq-iosched.c
@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
if (cfqq == RQ_CFQQ(rq))
return 1;
- return 1;
+
On Tue, Jan 02 2007, Rene Herman wrote:
Jens Axboe wrote:
On Mon, Jan 01 2007, Andrew Morton wrote:
The patch would appear to need this fix:
--- a/block/cfq-iosched.c~a
+++ a/block/cfq-iosched.c
@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
if (cfqq == RQ_CFQQ(rq))
On Tue, Jan 02 2007, Jens Axboe wrote:
On Tue, Jan 02 2007, Rene Herman wrote:
Jens Axboe wrote:
On Mon, Jan 01 2007, Andrew Morton wrote:
The patch would appear to need this fix:
--- a/block/cfq-iosched.c~a
+++ a/block/cfq-iosched.c
@@ -592,7 +592,7 @@ static int
Jens Axboe wrote:
But surely one of (not sure which) sync+async or async+sync may also be
okay?
Or would it?
Async merge to sync request should be ok. But I wonder what happens with
hdparm, since it seems to trigger one of these tests. Very puzzling.
I'll dive in and take a look.
The code
Jens Axboe wrote:
On Tue, Jan 02 2007, Jens Axboe wrote:
On Tue, Jan 02 2007, Rene Herman wrote:
Jens Axboe wrote:
On Mon, Jan 01 2007, Andrew Morton wrote:
The patch would appear to need this fix:
--- a/block/cfq-iosched.c~a
+++ a/block/cfq-iosched.c
@@ -592,7 +592,7 @@ static int
On Tue, Jan 02 2007, Mark Lord wrote:
Jens Axboe wrote:
On Tue, Jan 02 2007, Jens Axboe wrote:
On Tue, Jan 02 2007, Rene Herman wrote:
Jens Axboe wrote:
On Mon, Jan 01 2007, Andrew Morton wrote:
The patch would appear to need this fix:
--- a/block/cfq-iosched.c~a
+++
Jens Axboe wrote:
I did have to massage the second patch to get it to apply cleanly
after the first patch. You may want to regenerate it against -rc3.
Hmm odd, I thought I did. Will double check.
Ahh.. I get it now.
I tried to apply the second patch *on top* of the first patch,
whereas
On Tue, Jan 02 2007, Mark Lord wrote:
Jens Axboe wrote:
I did have to massage the second patch to get it to apply cleanly
after the first patch. You may want to regenerate it against -rc3.
Hmm odd, I thought I did. Will double check.
Ahh.. I get it now.
I tried to apply the second
Mark Lord wrote:
The code (written 10 years ago) isn't the best in the world,
and will be redone entirely for hdparm-7.0 this year.
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block. Support for
IDENTIFY PACKET DEVICE
On Jan 2 2007 10:01, Mark Lord wrote:
Jens Axboe wrote:
But surely one of (not sure which) sync+async or async+sync may also
be okay?
Or would it?
Async merge to sync request should be ok. But I wonder what happens with
hdparm, since it seems to trigger one of these tests. Very
Tejun Heo wrote:
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block.
hdparm -I works just fine now.
hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
to retrieve the boot time copy of the identify
Mark Lord wrote:
Tejun Heo wrote:
OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block.
hdparm -I works just fine now.
No objection there.
hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
to
Tejun Heo wrote:
Mark Lord wrote:
Support for IDENTIFY PACKET DEVICE would be nice too.
It already does that, using HDIO_DRIVE_CMD to retrieve it
in the same way as for regular IDENTIFY DEVICE commands.
Hmmm... My hdparm doesn't seem to do that.
Sure it does.
Try strace hdparm -I /dev/sr0
On Mon, 01 Jan 2007 23:46:58 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> > Everything seems fine in the dmesg. Performance degradation is
> > probably some other issue in -rc kernel. I'm suspecting recently
> > fixed block layer bug. If it's still the same in the next -rc,
> > please
Rene Herman wrote:
Tejun Heo wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the same in the next -rc,
please report.
In fact, it's CFQ. The PATA thing was a red
On Mon, 1 Jan 2007, Rene Herman wrote:
> Rene Herman wrote:
>
> > In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3 give
> > me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below give me ~
> > 50 MB/s.
> >
> > Jens: this is due to "[PATCH] cfq-iosched: tighten
Rene Herman wrote:
In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
give me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below
give me ~ 50 MB/s.
Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge
criteria",
Rene Herman wrote:
In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
give me ~ 24 MB/s from hdparm t /dev/hda while 2.6.20-rc1 and below
give me ~ 50 MB/s.
Jens: this is due to [PATCH] cfq-iosched: tighten allow merge
criteria, 719d34027e1a186e46a3952e8a24bf91ecc33837:
On Mon, 1 Jan 2007, Rene Herman wrote:
Rene Herman wrote:
In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3 give
me ~ 24 MB/s from hdparm t /dev/hda while 2.6.20-rc1 and below give me ~
50 MB/s.
Jens: this is due to [PATCH] cfq-iosched: tighten allow merge
Rene Herman wrote:
Tejun Heo wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the same in the next -rc,
please report.
In fact, it's CFQ. The PATA thing was a red
On Mon, 01 Jan 2007 23:46:58 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Everything seems fine in the dmesg. Performance degradation is
probably some other issue in -rc kernel. I'm suspecting recently
fixed block layer bug. If it's still the same in the next -rc,
please report.
In
38 matches
Mail list logo
