This is the final draft of the non-blocking hard disk resume patch. I've
included some performance results to demonstrate the real benefits
of this patch. Please note that this patch provides a MASSIVE performance
improvement in hard disk resume. It's too valuable to ignore, so I really
need the he
Part 2 of the hard disk resume optimization patch, this one applies
to the scsi subsystem.
Signed-off-by: Todd Brandt
Signed-off-by: Arjan van de Ven
drivers/scsi/sd.c | 82
-
1 file changed, 81 insertions(+), 1
t 07:03:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Thursday, September 05, 2013 05:44:25 PM Todd E Brandt wrote:
> > Part 2 of the hard disk resume optimization patch, this one applies
> > to the scsi subsystem.
>
> Please update the patch
I'll fix those, thanks for the feedback.
On Fri, Sep 06, 2013 at 04:37:00PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 06-09-2013 4:44, Todd E Brandt wrote:
>
> >Part 2 of the hard disk resume optimization patch, this one applies
> >to the scsi subsystem.
>
.
This approach is really the only remaining way (that I can think of) to
remove the ata-port wakeup delay in software, so given the massive
performance benefit I hope you'll consider it. Thanks for the reply!
On Fri, Sep 06, 2013 at 08:10:34AM -0700, James Bottomley wrote:
> On Th
On Fri, Sep 06, 2013 at 06:54:48PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Thursday, September 05, 2013 05:38:53 PM Todd E Brandt wrote:
> > This is the final draft of the non-blocking hard disk resume patch. I've
> > included some performance re
The essential issue behind hard disks' lengthy resume time is the ata port
driver blocking until the ATA port hardware is finished coming online. So the
kernel isn't really doing anything during all those seconds that the disks are
resuming, it's just blocking until the hardware says it's ready
On resume, the ATA port driver currently waits until the AHCI controller
finishes executing the port wakeup command. This patch changes the
ata_port_resume callback to issue the wakeup and then return immediately, thus
allowing the next device in the pm queue to resume. Any commands issued to th
On resume, the SD driver currently waits until the block driver finishes
executing a disk start command with blk_execute_rq. This patch changes the
sd_resume callback to use blk_execute_rq_nowait instead, which allows it to
return immediately, thus allowing the next device in the pm queue to res
llip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 10/17/2013 03:33 PM, Todd E Brandt wrote:
> > The essential issue behind hard disks' lengthy resume time is the
> > ata port driver blocking until the ATA port hardware is finished
> > co
> On 11/08/2013 08:20 PM, Todd E Brandt wrote:
> > I tested your patches and they do function. We tried a similar
> > approach a few months back where instead of waking the scsi disks
> > we just set them all to runtime_suspended and skipped the resume.
> > Then we let them
On resume, the ATA port driver currently waits until the AHCI controller
finishes executing the port wakeup command. This patch changes the
ata_port_resume callback to issue the wakeup and then return immediately,
thus allowing the next device in the pm queue to resume. Any commands issued
to t
On resume, the SD driver currently waits until the block driver finishes
executing a disk start command with blk_execute_rq. This patch changes the
sd_resume callback to use blk_execute_rq_nowait instead, which allows it to
return immediately, thus allowing the next device in the pm queue to res
Hi James, can you give me some feedback on this patch set? It includes
changes based on your feedback to v1.
The essential issue behind hard disks' lengthy resume time is the ata port
driver blocking until the ATA port hardware is finished coming online. So
the kernel isn't really doing anything
This patch reduces S3 resume time from 10+ seconds to less than a second
on systems with SATA drives. It does this by making ata port and scsi disk
resume non-blocking.
This is another resend of the patch I send out in early December. I've
addressed all the feedback I received from list members, s
On resume, the ATA port driver currently waits until the AHCI controller
finishes executing the port wakeup command. This patch changes the
ata_port_resume callback to issue the wakeup and then return immediately,
thus allowing the next device in the pm queue to resume. Any commands
issued to the A
On resume, the SD driver currently waits until the block driver finishes
executing a disk start command with blk_execute_rq. This patch changes
the sd_resume callback to use blk_execute_rq_nowait instead, which allows
it to return immediately, thus allowing the next device in the pm queue
to resume
On Sat, Jan 11, 2014 at 02:13:15PM -0500, Tejun Heo wrote:
> Hello,
>
> On Tue, Jan 07, 2014 at 04:56:07PM -0800, Todd E Brandt wrote:
> > On resume, the ATA port driver currently waits until the AHCI controller
> > finishes executing the port wakeup command. This patch chan
On Fri, Jan 10, 2014 at 07:13:11PM -0800, Dan Williams wrote:
> On Fri, Jan 10, 2014 at 6:13 PM, Phillip Susi wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > On 01/10/2014 06:11 PM, Brandt, Todd E wrote:
> >> Yes yours is simpler, but it also opens a potential memory issue
>
On Mon, Jan 13, 2014 at 03:30:07PM -0500, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 13, 2014 at 11:55:44AM -0800, Todd E Brandt wrote:
> > I see your point, why have two paths if one will do. The only thing that
> > worries me is that the PM resume from hibernate functio
On Mon, Jan 13, 2014 at 12:37:01PM -0800, Dan Williams wrote:
> On Mon, Jan 13, 2014 at 12:06 PM, Todd E Brandt
> wrote:
> > On Fri, Jan 10, 2014 at 07:13:11PM -0800, Dan Williams wrote:
> >> On Fri, Jan 10, 2014 at 6:13 PM, Phillip Susi wrote:
> >> &
On Tue, Jan 14, 2014 at 09:43:25AM -0500, Tejun Heo wrote:
> Hello, Gwendal.
>
> On Mon, Jan 13, 2014 at 04:36:52PM -0800, Gwendal Grignou wrote:
> > Won't this patch defeat staggered spinup at resume? If you have a jbod
> > with a smallish power supply, with a 12V rail designed for the steady
> >
On resume, the ATA port driver currently waits until the AHCI controller
finishes executing the port wakeup command. This patch changes the
ata_port_resume callback to issue the wakeup and then return immediately,
thus allowing the next device in the pm queue to resume. Any commands
issued to the A
This patch reduces S3 resume time from 10+ seconds to less than a second
on systems with SATA drives. It does this by making ata port and scsi disk
resume non-blocking.
This is another resend of the patch I send out in early December. I've
addressed all the feedback I received from list members, s
On resume, the SD driver currently waits until the block driver finishes
executing a disk start command with blk_execute_rq. This patch changes
the sd_resume callback to use blk_execute_rq_nowait instead, which allows
it to return immediately, thus allowing the next device in the pm queue
to resume
On Wed, Jan 15, 2014 at 08:01:04AM -0500, Tejun Heo wrote:
> Hello,
>
> On Tue, Jan 14, 2014 at 04:31:40PM -0800, Todd E Brandt wrote:
>
> > Signed-off-by: Todd Brandt
> > Signed-off-by: Arjan van de Ven
> >
> > drivers/ata/libata-core.c | 32
This patch reduces S3 resume time from 10+ seconds to less than a second
on systems with SATA drives. It does this by making ata port and scsi disk
resume non-blocking.
This is v4, sent in response to Tejun Huo's comments and with some small
fixes made after testing.
OVERVIEW
The essential issue
On resume, the ATA port driver currently waits until the AHCI controller
finishes executing the port wakeup command. This patch changes the
ata_port_resume callback to issue the wakeup and then return immediately,
thus allowing the next device in the pm queue to resume. Any commands
issued to the A
On resume, the SD driver currently waits until the block driver finishes
executing a disk start command with blk_execute_rq. This patch changes
the sd_resume callback to use blk_execute_rq_nowait instead, which allows
it to return immediately, thus allowing the next device in the pm queue
to resume
On Thu, Jan 16, 2014 at 11:59:43AM -0500, Alan Stern wrote:
> Folks:
>
> I would like to tie together separate email threads regarding disk
> spin-up time during system resume.
>
> Todd has posted some patches to make spin-up occur asynchronously, thus
> not delaying the return of the system to n
On Thu, Jan 16, 2014 at 03:05:40PM -0500, Alan Stern wrote:
> On Thu, 16 Jan 2014, Todd E Brandt wrote:
>
> > > Does this plan sound reasonable to everyone? Are there important
> > > aspects I haven't considered (such as interactions between the SCSI and
> &g
On Fri, Jan 17, 2014 at 09:57:47AM -0500, Alan Stern wrote:
> On Thu, 16 Jan 2014, Todd E Brandt wrote:
>
> > On Thu, Jan 16, 2014 at 03:05:40PM -0500, Alan Stern wrote:
> > > On Thu, 16 Jan 2014, Todd E Brandt wrote:
> > >
> > > > > Does this
On Fri, Jan 17, 2014 at 03:24:33PM -0500, Tejun Heo wrote:
> On Fri, Jan 17, 2014 at 03:15:54PM -0500, Alan Stern wrote:
> > You will have to argue this point with Phillip.
> >
> > If necessary, we could add a sysfs attribute to force a spin-up during
> > system resume. Or you could disable runti
33 matches
Mail list logo
