Re: [RFC/PATCH] Deferred disk spinup during system resume

Re: [RFC/PATCH] Deferred disk spinup during system resume

[Jeff Garzik]

On 01/12/2011 03:01 PM, Maksim Rayskiy wrote:
>>
>> The bottom line is that this patch simply wants to trigger an ATA command,
>> and return immediately, discarding the command results.  I'm not even sure a
>> "run this command in background, and discard results" facility requires the
>> EH.
>>
>
> This is why I was asking if using a workqueue instead of EH might be a
> better idea.
> EH looks like an overkill here.

A kernel modification might not even be needed.

Have you tried simply issuing READ VERIFY via bsg, and not caring if it 
completes?  bsg should be able to handle an app submitting a command, 
but never checking the 'done' list, right?  A simple shell app could execute

	write(bsg_fd, ... SCSI READ VERIFY command ...)
	exit(0)

to avoid waiting for READ VERIFY command completion, I would hope.

	Jeff

Re: [RFC/PATCH] Deferred disk spinup during system resume

[Maksim Rayskiy]

> A kernel modification might not even be needed.
>
> Have you tried simply issuing READ VERIFY via bsg, and not caring if it
> completes?  bsg should be able to handle an app submitting a command, but
> never checking the 'done' list, right?  A simple shell app could execute
>
>        write(bsg_fd, ... SCSI READ VERIFY command ...)
>        exit(0)
>
> to avoid waiting for READ VERIFY command completion, I would hope.
>
>        Jeff
>

My question was how to speed up system resume when he the spinup
request is coming from sd_resume(). For shell method to work I would
have to ignore this request entirely and do READ VERIFY when system is
fully restored.
Can it be done without kernel modification? Tejun mentioned using
manage_start_stop flag but had some reservations against it.

Maksim.

Re: [RFC/PATCH] Deferred disk spinup during system resume

[Jeff Garzik]

On 01/19/2011 03:29 PM, Maksim Rayskiy wrote:
>> A kernel modification might not even be needed.
>>
>> Have you tried simply issuing READ VERIFY via bsg, and not caring if it
>> completes?  bsg should be able to handle an app submitting a command, but
>> never checking the 'done' list, right?  A simple shell app could execute
>>
>>         write(bsg_fd, ... SCSI READ VERIFY command ...)
>>         exit(0)
>>
>> to avoid waiting for READ VERIFY command completion, I would hope.
>>
>>         Jeff
>>
>
> My question was how to speed up system resume when he the spinup
> request is coming from sd_resume(). For shell method to work I would
> have to ignore this request entirely and do READ VERIFY when system is
> fully restored.
> Can it be done without kernel modification? Tejun mentioned using
> manage_start_stop flag but had some reservations against it.

Oh, if we're talking about sd_resume(), SCSI definitely has an internal 
mechanism to fire off a request, without blocking and waiting for a 
response.  It does sound like a kernel modification, but it should be 
straightforward via existing APIs.

	Jeff