-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 7:15 AM, Tejun Heo wrote:
> On Mon, Nov 11, 2013 at 12:08:49PM -0500, Phillip Susi wrote:
>> No, I did not tune my system; I fixed the kernel so that
>> userspace's activities do not start those disks.
>
> So, umm, implementing things in
On Mon, Nov 11, 2013 at 12:08:49PM -0500, Phillip Susi wrote:
> No, I did not tune my system; I fixed the kernel so that userspace's
> activities do not start those disks.
So, umm, implementing things in kernel to facilitate userland is great
but please don't try to work around userland from kerne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/17/2013 3:33 PM, Todd E Brandt wrote:
> sd_resume patch (2/2):
>
> 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 us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2013 11:59 AM, Todd E Brandt wrote:
> 500ms is actually quite alot when you compare it with android or
> iOS, or even with other subsystems like USB. USB is the second
> worst offender after SATA disks and it tends to take around 600ms
> for m
500ms is actually quite alot when you compare it with android or iOS,
or even with other subsystems like USB. USB is the second worst offender
after SATA disks and it tends to take around 600ms for most standard
systems with an onboard webcam, and with other devices plugged in ever
longer. I thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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.
> Th
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 be awakened later by read/write access just as you have. It's a really
tempting appro
-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
> coming online. So the kernel isn't really doing anything during all
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
9 matches
Mail list logo
