From: Jake Ellowitz <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
To: Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Kernel Testers List
<kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Subject: Re: [Bug #13463] Poor SSD performance
Date: Tue, 16 Jun 2009 00:09:17 -0400 [thread overview]
Message-ID: <4A371AED.5080800@uchicago.edu> (raw)
In-Reply-To: <20090611031153.GA7007@localhost>
Dear Fengguang,
Thanks so much for the attention you paid to this problem. I did not
want to respond until I got a chance to give the new kernel a shot to
see if the bug was still present. It appears not to be -- hdparm and dd
both register read speeds between 200 and 220 MB/s as opposed to the 70
to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange
bug has sort of resolved itself.
Best,
Jake
Wu Fengguang wrote:
> On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote:
>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463
>>> Subject : Poor SSD performance
>>> Submitter : Jake <ellowitz-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
>>> Date : 2009-06-05 17:37 (3 days old)
>>>
>> Hi Jake,
>>
>> Could you collect some blktrace data for the dd commands on new/old
>> kernels?
>>
>> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
>> dd if=/dev/sda of=/dev/null bs=1M count=1024
>>
>
> I managed to get a SanDisk SSD for testing, and observes that
>
> - one must increase read_ahead_kb to at least max_sectors_kb or better
> "bs=1M" to make a fair comparison
> - with increased readahead size, the dd reported throughputs are
> 75MB/s vs 77MB/s, while the blktrace reported throughputs are
> 75MB/s vs 75MB/s (buffered IO vs direct IO).
>
> Here are details.
>
> The dd throughputs are equal for rotational hard disks, but differs
> for this SanDisk SSD (with default RA parameters):
>
> % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024
> 1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s
> 1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s
>
> % dd if=/dev/sda of=/dev/null bs=1M count=1024
> 1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s
> 1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s
>
> Here is the blktrace summary:
>
> dd dd-direct
> --------------------------------------------------------------------------------------
> CPU0 (sda): | CPU0 (sda):
> Reads Queued: 9,888, 39,552KiB | Reads Queued: 84, 43,008KiB
> Read Dispatches: 302, 38,588KiB | Read Dispatches: 84, 43,008KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 337, 44,600KiB | Reads Completed: 83, 42,496KiB
> Read Merges: 9,574, 38,296KiB | Read Merges: 0, 0KiB
> Read depth: 2 | Read depth: 2
> IO unplugs: 313 | IO unplugs: 42
> CPU1 (sda): | CPU1 (sda):
> Reads Queued: 11,840, 47,360KiB | Reads Queued: 96, 49,152KiB
> Read Dispatches: 372, 48,196KiB | Read Dispatches: 96, 49,152KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 337, 42,312KiB | Reads Completed: 96, 49,152KiB
> Read Merges: 11,479, 45,916KiB | Read Merges: 0, 0KiB
> Read depth: 2 | Read depth: 2
> IO unplugs: 372 | IO unplugs: 48
> |
> Total (sda): | Total (sda):
> Reads Queued: 21,728, 86,912KiB | Reads Queued: 180, 92,160KiB
> Read Dispatches: 674, 86,784KiB | Read Dispatches: 180, 92,160KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 674, 86,912KiB | Reads Completed: 179, 91,648KiB
> Read Merges: 21,053, 84,212KiB | Read Merges: 0, 0KiB
> IO unplugs: 685 | IO unplugs: 90
> |
> Throughput (R/W): 69,977KiB/s / 0KiB/s | Throughput (R/W): 75,368KiB/s / 0KiB/s
> Events (sda): 46,804 entries | Events (sda): 1,158 entries
>
>
> Another obvious difference is IO size.
> One is read_ahead_kb=128K, another is max_sectors_kb=512K:
>
> dd:
> 8,0 0 13497 0.804939305 0 C R 782592 + 256 [0]
> 8,0 0 13498 0.806713692 0 C R 782848 + 256 [0]
> 8,0 1 16275 0.808488708 0 C R 783104 + 256 [0]
> 8,0 0 13567 0.810261350 0 C R 783360 + 256 [0]
> 8,0 0 13636 0.812036226 0 C R 783616 + 256 [0]
> 8,0 1 16344 0.813806353 0 C R 783872 + 256 [0]
> 8,0 1 16413 0.815578436 0 C R 784128 + 256 [0]
> 8,0 0 13705 0.817347935 0 C R 784384 + 256 [0]
>
> dd-direct:
> 8,0 0 428 0.998831975 0 C R 357376 + 1024 [0]
> 8,0 1 514 1.005683404 0 C R 358400 + 1024 [0]
> 8,0 1 515 1.012402554 0 C R 359424 + 1024 [0]
> 8,0 0 440 1.019303850 0 C R 360448 + 1024 [0]
> 8,0 1 526 1.026024048 0 C R 361472 + 1024 [0]
> 8,0 1 538 1.032875967 0 C R 362496 + 1024 [0]
> 8,0 0 441 1.039595815 0 C R 363520 + 1024 [0]
>
> The non-direct dd throughput can improve with 512K and 1M readahead size,
> but still a bit slower than the direct dd case:
> 1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s
> 1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s
>
> dd-512k dd-direct2
> -------------------------------------------------------------------------------------
> Total (sda): | Total (sda):
> Reads Queued: 23,808, 95,232KiB | Reads Queued: 178, 91,136KiB
> Read Dispatches: 215, 95,232KiB | Read Dispatches: 178, 91,136KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 215, 95,232KiB | Reads Completed: 177, 90,624KiB
> Read Merges: 23,593, 94,372KiB | Read Merges: 0, 0KiB
> IO unplugs: 236 | IO unplugs: 89
> |
> Throughput (R/W): 75,222KiB/s / 0KiB/s | Throughput (R/W): 75,520KiB/s / 0KiB/s
> Events (sda): 48,687 entries | Events (sda): 1,145 entries
>
> Interestingly, the throughput reported by blktrace is almost the same,
> whereas the dd report favors the dd-direct case.
>
> More parameters.
>
> [ 10.137350] scsi 3:0:0:0: Direct-Access ATA SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5
> [ 10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB)
> [ 10.155060] sd 3:0:0:0: [sda] Write Protect is off
> [ 10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [ 10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [ 10.174994] sda:
>
>
> /dev/sda:
>
> Model=SanDisk SSD SATA 5000 2.5 , FwRev=1.13 , SerialNo= 81402200246
> Config={ Fixed }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
> BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1?
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000
> IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2
> UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
> AdvancedPM=yes: disabled (255) WriteCache=disabled
> Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7
>
> * signifies the current active mode
>
>
> /sys/block/sda/queue/nr_requests:128
> /sys/block/sda/queue/read_ahead_kb:128
> /sys/block/sda/queue/max_hw_sectors_kb:32767
> /sys/block/sda/queue/max_sectors_kb:512
> /sys/block/sda/queue/scheduler:noop [cfq]
> /sys/block/sda/queue/hw_sector_size:512
> /sys/block/sda/queue/rotational:1
> /sys/block/sda/queue/nomerges:0
> /sys/block/sda/queue/rq_affinity:0
> /sys/block/sda/queue/iostats:1
> /sys/block/sda/queue/iosched/quantum:4
> /sys/block/sda/queue/iosched/fifo_expire_sync:124
> /sys/block/sda/queue/iosched/fifo_expire_async:248
> /sys/block/sda/queue/iosched/back_seek_max:16384
> /sys/block/sda/queue/iosched/back_seek_penalty:2
> /sys/block/sda/queue/iosched/slice_sync:100
> /sys/block/sda/queue/iosched/slice_async:40
> /sys/block/sda/queue/iosched/slice_async_rq:2
> /sys/block/sda/queue/iosched/slice_idle:8
>
> Thanks,
> Fengguang
>
WARNING: multiple messages have this Message-ID (diff)
From: Jake Ellowitz <ellowitz@uchicago.edu>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kernel Testers List <kernel-testers@vger.kernel.org>,
tj@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [Bug #13463] Poor SSD performance
Date: Tue, 16 Jun 2009 00:09:17 -0400 [thread overview]
Message-ID: <4A371AED.5080800@uchicago.edu> (raw)
In-Reply-To: <20090611031153.GA7007@localhost>
Dear Fengguang,
Thanks so much for the attention you paid to this problem. I did not
want to respond until I got a chance to give the new kernel a shot to
see if the bug was still present. It appears not to be -- hdparm and dd
both register read speeds between 200 and 220 MB/s as opposed to the 70
to 80 MB/s I was getting with kernel 2.6.29. So, I guess this strange
bug has sort of resolved itself.
Best,
Jake
Wu Fengguang wrote:
> On Wed, Jun 10, 2009 at 02:37:46PM +0800, Wu Fengguang wrote:
>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13463
>>> Subject : Poor SSD performance
>>> Submitter : Jake <ellowitz@uchicago.edu>
>>> Date : 2009-06-05 17:37 (3 days old)
>>>
>> Hi Jake,
>>
>> Could you collect some blktrace data for the dd commands on new/old
>> kernels?
>>
>> dd if=/dev/sda of=/dev/null bs=1M count=1024 iflag=direct
>> dd if=/dev/sda of=/dev/null bs=1M count=1024
>>
>
> I managed to get a SanDisk SSD for testing, and observes that
>
> - one must increase read_ahead_kb to at least max_sectors_kb or better
> "bs=1M" to make a fair comparison
> - with increased readahead size, the dd reported throughputs are
> 75MB/s vs 77MB/s, while the blktrace reported throughputs are
> 75MB/s vs 75MB/s (buffered IO vs direct IO).
>
> Here are details.
>
> The dd throughputs are equal for rotational hard disks, but differs
> for this SanDisk SSD (with default RA parameters):
>
> % dd if=/dev/sda of=/dev/null iflag=direct bs=1M count=1024
> 1073741824 bytes (1.1 GB) copied, 13.905 s, 77.2 MB/s
> 1073741824 bytes (1.1 GB) copied, 13.9029 s, 77.2 MB/s
>
> % dd if=/dev/sda of=/dev/null bs=1M count=1024
> 1073741824 bytes (1.1 GB) copied, 14.7294 s, 72.9 MB/s
> 1073741824 bytes (1.1 GB) copied, 14.8647 s, 72.2 MB/s
>
> Here is the blktrace summary:
>
> dd dd-direct
> --------------------------------------------------------------------------------------
> CPU0 (sda): | CPU0 (sda):
> Reads Queued: 9,888, 39,552KiB | Reads Queued: 84, 43,008KiB
> Read Dispatches: 302, 38,588KiB | Read Dispatches: 84, 43,008KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 337, 44,600KiB | Reads Completed: 83, 42,496KiB
> Read Merges: 9,574, 38,296KiB | Read Merges: 0, 0KiB
> Read depth: 2 | Read depth: 2
> IO unplugs: 313 | IO unplugs: 42
> CPU1 (sda): | CPU1 (sda):
> Reads Queued: 11,840, 47,360KiB | Reads Queued: 96, 49,152KiB
> Read Dispatches: 372, 48,196KiB | Read Dispatches: 96, 49,152KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 337, 42,312KiB | Reads Completed: 96, 49,152KiB
> Read Merges: 11,479, 45,916KiB | Read Merges: 0, 0KiB
> Read depth: 2 | Read depth: 2
> IO unplugs: 372 | IO unplugs: 48
> |
> Total (sda): | Total (sda):
> Reads Queued: 21,728, 86,912KiB | Reads Queued: 180, 92,160KiB
> Read Dispatches: 674, 86,784KiB | Read Dispatches: 180, 92,160KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 674, 86,912KiB | Reads Completed: 179, 91,648KiB
> Read Merges: 21,053, 84,212KiB | Read Merges: 0, 0KiB
> IO unplugs: 685 | IO unplugs: 90
> |
> Throughput (R/W): 69,977KiB/s / 0KiB/s | Throughput (R/W): 75,368KiB/s / 0KiB/s
> Events (sda): 46,804 entries | Events (sda): 1,158 entries
>
>
> Another obvious difference is IO size.
> One is read_ahead_kb=128K, another is max_sectors_kb=512K:
>
> dd:
> 8,0 0 13497 0.804939305 0 C R 782592 + 256 [0]
> 8,0 0 13498 0.806713692 0 C R 782848 + 256 [0]
> 8,0 1 16275 0.808488708 0 C R 783104 + 256 [0]
> 8,0 0 13567 0.810261350 0 C R 783360 + 256 [0]
> 8,0 0 13636 0.812036226 0 C R 783616 + 256 [0]
> 8,0 1 16344 0.813806353 0 C R 783872 + 256 [0]
> 8,0 1 16413 0.815578436 0 C R 784128 + 256 [0]
> 8,0 0 13705 0.817347935 0 C R 784384 + 256 [0]
>
> dd-direct:
> 8,0 0 428 0.998831975 0 C R 357376 + 1024 [0]
> 8,0 1 514 1.005683404 0 C R 358400 + 1024 [0]
> 8,0 1 515 1.012402554 0 C R 359424 + 1024 [0]
> 8,0 0 440 1.019303850 0 C R 360448 + 1024 [0]
> 8,0 1 526 1.026024048 0 C R 361472 + 1024 [0]
> 8,0 1 538 1.032875967 0 C R 362496 + 1024 [0]
> 8,0 0 441 1.039595815 0 C R 363520 + 1024 [0]
>
> The non-direct dd throughput can improve with 512K and 1M readahead size,
> but still a bit slower than the direct dd case:
> 1073741824 bytes (1.1 GB) copied, 14.1619 s, 75.8 MB/s
> 1073741824 bytes (1.1 GB) copied, 14.1517 s, 75.9 MB/s
>
> dd-512k dd-direct2
> -------------------------------------------------------------------------------------
> Total (sda): | Total (sda):
> Reads Queued: 23,808, 95,232KiB | Reads Queued: 178, 91,136KiB
> Read Dispatches: 215, 95,232KiB | Read Dispatches: 178, 91,136KiB
> Reads Requeued: 0 | Reads Requeued: 0
> Reads Completed: 215, 95,232KiB | Reads Completed: 177, 90,624KiB
> Read Merges: 23,593, 94,372KiB | Read Merges: 0, 0KiB
> IO unplugs: 236 | IO unplugs: 89
> |
> Throughput (R/W): 75,222KiB/s / 0KiB/s | Throughput (R/W): 75,520KiB/s / 0KiB/s
> Events (sda): 48,687 entries | Events (sda): 1,145 entries
>
> Interestingly, the throughput reported by blktrace is almost the same,
> whereas the dd report favors the dd-direct case.
>
> More parameters.
>
> [ 10.137350] scsi 3:0:0:0: Direct-Access ATA SanDisk SSD SATA 1.13 PQ: 0 ANSI: 5
> [ 10.147137] sd 3:0:0:0: [sda] 61500000 512-byte hardware sectors: (31.4 GB/29.3 GiB)
> [ 10.155060] sd 3:0:0:0: [sda] Write Protect is off
> [ 10.159922] sd 3:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [ 10.165179] sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [ 10.174994] sda:
>
>
> /dev/sda:
>
> Model=SanDisk SSD SATA 5000 2.5 , FwRev=1.13 , SerialNo= 81402200246
> Config={ Fixed }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
> BuffType=unknown, BuffSize=0kB, MaxMultSect=1, MultSect=?1?
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=61500000
> IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2
> UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
> AdvancedPM=yes: disabled (255) WriteCache=disabled
> Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7
>
> * signifies the current active mode
>
>
> /sys/block/sda/queue/nr_requests:128
> /sys/block/sda/queue/read_ahead_kb:128
> /sys/block/sda/queue/max_hw_sectors_kb:32767
> /sys/block/sda/queue/max_sectors_kb:512
> /sys/block/sda/queue/scheduler:noop [cfq]
> /sys/block/sda/queue/hw_sector_size:512
> /sys/block/sda/queue/rotational:1
> /sys/block/sda/queue/nomerges:0
> /sys/block/sda/queue/rq_affinity:0
> /sys/block/sda/queue/iostats:1
> /sys/block/sda/queue/iosched/quantum:4
> /sys/block/sda/queue/iosched/fifo_expire_sync:124
> /sys/block/sda/queue/iosched/fifo_expire_async:248
> /sys/block/sda/queue/iosched/back_seek_max:16384
> /sys/block/sda/queue/iosched/back_seek_penalty:2
> /sys/block/sda/queue/iosched/slice_sync:100
> /sys/block/sda/queue/iosched/slice_async:40
> /sys/block/sda/queue/iosched/slice_async_rq:2
> /sys/block/sda/queue/iosched/slice_idle:8
>
> Thanks,
> Fengguang
>
next prev parent reply other threads:[~2009-06-16 4:09 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-07 10:02 2.6.30-rc8-git4: Reported regressions 2.6.28 -> 2.6.29 Rafael J. Wysocki
2009-06-07 10:02 ` Rafael J. Wysocki
2009-06-07 10:03 ` [Bug #12490] ath5k related kernel panic in 2.6.29-rc1 Rafael J. Wysocki
2009-06-07 10:03 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12971] "tg3 transmit timed out" when transmitting at high bitrate Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12765] i915 VT switch with AIGLX causes X lock up Rafael J. Wysocki
2009-06-28 20:11 ` Sitsofe Wheeler
2009-06-28 20:11 ` Sitsofe Wheeler
2009-07-20 18:11 ` Jesse Barnes
2009-06-07 10:06 ` [Bug #12909] boot/kernel init duration regression from 2.6.28 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12681] s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled) Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12899] Crash in i915.ko: i915_driver_irq_handler Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13017] ATA bus errors on resume Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13024] nozomi: pppd fails on kernel 2.6.29 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #12980] lockup in X.org Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13001] PCI-DMA: Out of IOMMU space Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13025] After upgrading to kernel 2.6.29, pulseaudio stopped with some strange error Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13074] gspca_stv06xx doesn't work with Logitech QuickCam Express (046d:0840) Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13072] forcedeth seems to switch off eth on shutdown Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 17:14 ` Robert Hancock
[not found] ` <4A2BF577.1050003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2009-06-07 20:50 ` Rafael J. Wysocki
2009-06-07 20:50 ` Rafael J. Wysocki
2009-06-07 17:14 ` Robert Hancock
2009-06-07 10:06 ` [Bug #13144] resume from suspend fails using video card i915 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13100] can't anymore even do a s2ram-s2disk-s2ram cycle on acer aspire 5720G Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13148] resume after suspend-to-ram broken on Sony Vaio VGN-SR19VN when sony-laptop driver present Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13178] Booting very slow Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-08 8:46 ` Martin Knoblauch
2009-06-08 8:46 ` Martin Knoblauch
[not found] ` <712849.19962.qm-VAEUvbQToQWvuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2009-06-08 11:12 ` Rafael J. Wysocki
2009-06-08 11:12 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13232] ext3/4 with synchronous writes gets wedged by Postfix Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 17:14 ` Theodore Tso
2009-06-07 17:14 ` Theodore Tso
[not found] ` <20090607171418.GA22756-3s7WtUTddSA@public.gmane.org>
2009-06-07 17:17 ` Al Viro
2009-06-07 17:17 ` Al Viro
[not found] ` <20090607171739.GI8633-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2009-06-07 20:10 ` Theodore Tso
2009-06-07 20:10 ` Theodore Tso
2009-06-07 10:06 ` [Bug #13225] [2.6.29 regression] Software suspend no longer works Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13269] WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x3c/0x48() when resuming Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13375] Kernel crash with 2.6.29 + nfs + xfs (radix-tree) Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 20:09 ` Mike Dresser
2009-06-07 20:09 ` Mike Dresser
[not found] ` <alpine.DEB.1.10.0906071608010.3914-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>
2009-06-08 7:27 ` Mathias Kretschmer
2009-06-08 7:27 ` Mathias Kretschmer
[not found] ` <200906080927.10479.posting-ZcF2+9dVbKo@public.gmane.org>
2009-06-08 7:40 ` Mathias Kretschmer
2009-06-08 7:40 ` Mathias Kretschmer
[not found] ` <200906080940.14650.posting-ZcF2+9dVbKo@public.gmane.org>
2009-06-09 19:02 ` Mike Dresser
2009-06-09 19:02 ` Mike Dresser
[not found] ` <alpine.DEB.1.10.0906091457510.28108-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>
2009-06-09 19:11 ` Mathias Kretschmer
2009-06-09 19:11 ` Mathias Kretschmer
[not found] ` <200906092111.54073.mathias-ZcF2+9dVbKo@public.gmane.org>
2009-06-09 19:16 ` Mike Dresser
2009-06-09 19:16 ` Mike Dresser
2009-06-09 19:22 ` Mike Dresser
2009-06-09 19:22 ` Mike Dresser
[not found] ` <alpine.DEB.1.10.0906091521470.9067-SDjlOt0KSjdj8tndi7AXdQBQioIGk2LXAL8bYrjMMd8@public.gmane.org>
2009-06-15 17:25 ` Mike Dresser
2009-06-15 17:25 ` Mike Dresser
2009-06-18 21:55 ` Mathias Kretschmer
2009-06-18 21:55 ` Mathias Kretschmer
[not found] ` <200906182355.57100.mathias-ZcF2+9dVbKo@public.gmane.org>
2009-06-19 15:16 ` Mike Dresser
2009-06-19 15:16 ` Mike Dresser
2009-06-24 22:55 ` Mike Dresser
2009-06-24 22:55 ` Mike Dresser
[not found] ` <4A42AEEC.9070002-d1V2JtDI1HZNJje9z4SY99BPR1lH4CV8@public.gmane.org>
2009-06-25 6:14 ` Mathias Kretschmer
2009-06-25 6:14 ` Mathias Kretschmer
2009-06-07 10:06 ` [Bug #13371] s2disk hangs with e100, kernel 2.6.29 and later Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13339] rtable leak in ipv4/route.c Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13294] i915: drm: xorg leaks drm objects massively Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-07 13:50 ` Sergei Trofimovich
2009-06-07 13:50 ` Sergei Trofimovich
[not found] ` <20090607165018.4c946a30-b59k1isJxu/84SrubaaLTA@public.gmane.org>
2009-06-07 21:00 ` Rafael J. Wysocki
2009-06-07 21:00 ` Rafael J. Wysocki
2009-06-07 10:06 ` [Bug #13463] Poor SSD performance Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-10 6:37 ` Wu Fengguang
2009-06-10 6:37 ` Wu Fengguang
[not found] ` <20090611031153.GA7007@localhost>
2009-06-16 4:09 ` Jake Ellowitz [this message]
2009-06-16 4:09 ` Jake Ellowitz
[not found] ` <4A371AED.5080800-t4+EzPmVLfD2fBVCVOL8/A@public.gmane.org>
2009-06-16 12:28 ` Wu Fengguang
2009-06-16 12:28 ` Wu Fengguang
2009-06-07 10:06 ` [Bug #13411] Barscanner (USB HID Keyboard) stopped functioning in kernels >= 2.6.28 Rafael J. Wysocki
2009-06-07 10:06 ` Rafael J. Wysocki
2009-06-08 11:04 ` Jiri Kosina
2009-06-08 11:04 ` Jiri Kosina
[not found] ` <alpine.LNX.2.00.0906081302010.7457-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2009-06-08 11:37 ` Rafael J. Wysocki
2009-06-08 11:37 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A371AED.5080800@uchicago.edu \
--to=ellowitz-t4+ezpmvlfd2fbvcvol8/a@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rjw-KKrjLPT3xs0@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.