linux-kernel - Re: [RFC 3/4] libata: Remove excess command issue delays

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100217153402.44346f11@lxorguk.ukuu.org.uk>
Date:	Wed, 17 Feb 2010 15:34:02 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Sergei Shtylyov <sshtylyov@...sta.com>
Cc:	Alan Cox <alan@...ux.intel.com>, jeff@...zik.org.com,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [RFC 3/4] libata: Remove excess command issue delays

>    Wouldn't it make sense then to handle the "insane" hardware as an 
> exception, not vice versa?

It depends if you want to "fail safe". I'd personally just remove the
pause. We know from over ten years of drivers/ide that it's totally
unneccessary for almost any controller but I am submitting patches based
upon what Jeff seems ot want...

> > As a side effect it also means that those devices using PIO don't end up
> > generating ATA bus cycles in strange places which confuses some hardware.
> >   
> 
>    I thought that's mostly a problem with DMA commands...
> 
> > Saves us about 1mS on a dumb controller,
> 
>    1 ms per command?! Or per what?

per command. I've been using a plain and simple PCMCIA controller to make
the profiles nice and clear - the sff_pause does a read which crosses to
the device and back - that is slow. On some of the SFF style SATA
controllers its very fast so is presumably all cached as you'd expect.

Next time someone claims libata command issue is slower because of the
SCSI layer they should take a second look 8)

> > +	.sff_exec_command	= ata_sff_exec_command_nopost,
> > +	.sff_data_xfer	= 	winbond_data_xfer,
> > +	.cable_detect	= 	ata_cable_40wire,
> > +	.set_piomode	= 	winbond_set_piomode,
> >   
> 
>    What's up with the alignment here, why it's different from the rest 
> of drivers?
>
Just didn't fix up the formatting of that one when I was doing them all.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/