Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
On Sun, Sep 09, 2007 at 10:06:11PM -0400, Tom Evans wrote: I have done (and still do raid5) without performance impact (especially what I saw when the card was in a different slot). I will redo that array as raid5 to see if it makes a difference - I know software raid is expensive, just figured 6 wouldn't be too much more cpu intensive than level 5. I suspect raid6 uses more than twice the cpu overhead of raid5. raid5 is just parity, but raid6 has to do a bit more than just simple parity. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
I turned down the max rebuild speed quite a bit and it generates a raid-6 array without killing the machine (and in shorter time than when the limit is set at the default). It seems like the resync process is so greedy for bandwidth that it actually hurts itself if the CPU power is not there to support the bandwidth - this is what is surprising to me - that it can effectively lock out other tasks and still take longer to complete. When I turned the rebuild maxx speed down to 35000, the raid6 rebuild finished in 150 minutes. When left at the default, it finished in 350 minutes... Seems like the scheduler or the resync should be smarter about something..? ...tom On Mon, 10 Sep 2007 08:55:15 -0400, [EMAIL PROTECTED] (Lennart Sorensen) wrote: I suspect raid6 uses more than twice the cpu overhead of raid5. raid5 is just parity, but raid6 has to do a bit more than just simple parity. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
On Mon, Sep 10, 2007 at 12:59:25PM -0400, tom wrote: I turned down the max rebuild speed quite a bit and it generates a raid-6 array without killing the machine (and in shorter time than when the limit is set at the default). It seems like the resync process is so greedy for bandwidth that it actually hurts itself if the CPU power is not there to support the bandwidth - this is what is surprising to me - that it can effectively lock out other tasks and still take longer to complete. When I turned the rebuild maxx speed down to 35000, the raid6 rebuild finished in 150 minutes. When left at the default, it finished in 350 minutes... Seems like the scheduler or the resync should be smarter about something..? Yeah it probably should be. You could always file a bug report with the linux kernel and see if someone has an opinion on the behaviour. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
On Sun, Sep 09, 2007 at 12:17:16AM -0400, Tom Evans wrote: I use a 3124-2 based eSata card with a 4726-based port muliplier array/case, (plus the PMP patches). I then attempt to create a a raid6 array on 4 drives - the machine freezes something fierce during the process. Can barely key a keystroke in and the machine will not respond to pings. Well raid6 is pretty cpu intensive. Also during the initial sync it will by default try to use all disk bandwidth. You can adjust the max speed for resync using sysctl (or echo in /proc). By default the max is 20 KB/s, which I tend to change to 2 KB/s to make the machine useable while doing a resync. I have only done raid1 with software so far though (which is not cpu intensive at all). Not sure what difference the port expander would make. I moved the card (64bit PCI-X) to the first slot - things got better - the machine would go in and out of responsiveness. The array built in about 3 hours, but still seems weird. No unaligned access eating up time, that I checked. Maybe I can try a differnt eSata card with port multiplier support - any suggestions? Not sure how many support port multipliers. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
Lennart Sorensen wrote: On Sun, Sep 09, 2007 at 12:17:16AM -0400, Tom Evans wrote: Well raid6 is pretty cpu intensive. Also during the initial sync it will by default try to use all disk bandwidth. You can adjust the max speed for resync using sysctl (or echo in /proc). By default the max is 20 KB/s, which I tend to change to 2 KB/s to make the machine useable while doing a resync. I have only done raid1 with software so far though (which is not cpu intensive at all). Not sure what difference the port expander would make. I have done (and still do raid5) without performance impact (especially what I saw when the card was in a different slot). I will redo that array as raid5 to see if it makes a difference - I know software raid is expensive, just figured 6 wouldn't be too much more cpu intensive than level 5. ...tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
On Fri, Sep 07, 2007 at 11:26:36PM -0400, Tom Evans wrote: Darn - it was suggested that a performance issue I'm having with a Sil 3124 based pci-x esata card and a port multiplier might be helped with pre-emption enabled - just not for Alpha :) I know that the DS20 often has PCI issues - anyone know of what may cause issues with a 64bit PCI-X card on the machine? Any recommended placements for such thing? I have 3 64 bit cards in the machine, a VIA gig ethernet, a combo scsi/ethernet card and the 3124-2 based eSata card What kind of performance issues are you having? Sil (used to be CMD) hardly has a history of making good controllers. Rather on the contrary. Preempt tends to try and improve latancy for user applications at the expense of the kernel and drivers, so not likely to improve things for the sata controller, in fact more likely to give it even worse performance. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
On Fri, Sep 07, 2007 at 09:19:29AM -0400, Tom Evans wrote: Are there patches available for Alpha in the case that it does not? Not sure. I do not see a PREEMPT option in the config file on my alpha running Etch though, so I would suspect that it does not support preempt at this time. As for patches I have no idea. Looking at the kernel source I see preempt included only by: i386 mips parisc powerpc ppc x86_64 -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
Darn - it was suggested that a performance issue I'm having with a Sil 3124 based pci-x esata card and a port multiplier might be helped with pre-emption enabled - just not for Alpha :) I know that the DS20 often has PCI issues - anyone know of what may cause issues with a 64bit PCI-X card on the machine? Any recommended placements for such thing? I have 3 64 bit cards in the machine, a VIA gig ethernet, a combo scsi/ethernet card and the 3124-2 based eSata card Thanks, ...tom Lennart Sorensen wrote: On Fri, Sep 07, 2007 at 09:19:29AM -0400, Tom Evans wrote: Are there patches available for Alpha in the case that it does not? Not sure. I do not see a PREEMPT option in the config file on my alpha running Etch though, so I would suspect that it does not support preempt at this time. As for patches I have no idea. Looking at the kernel source I see preempt included only by: i386 mips parisc powerpc ppc x86_64 -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does the Linux kernel for alpha support CONFIG_PREEMPT?
I've included an lspci -v -v at the end in case anyone has any ideas what it all means ... ...tom I know that the DS20 often has PCI issues - anyone know of what may cause issues with a 64bit PCI-X card on the machine? Any recommended placements for such thing? I have 3 64 bit cards in the machine, a VIA gig ethernet, a combo scsi/ethernet card and the 3124-2 based eSata card lspci -v -v: :00:05.0 ISA bridge: Contaq Microsystems 82c693 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 :00:05.1 IDE interface: Contaq Microsystems 82c693 (prog-if 80 [Master]) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 14 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] Region 4: I/O ports at 9000 [size=16] :00:05.2 IDE interface: Contaq Microsystems 82c693 (prog-if 00 []) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 15 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] Region 4: Memory at 0a22 (32-bit, non-prefetchable) [disabled] [size=64K] :00:05.3 USB Controller: Contaq Microsystems 82c693 (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 248, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 10 Region 0: Memory at 0a24 (32-bit, non-prefetchable) [size=4K] :00:07.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) (prog-if 00 [VGA]) Subsystem: Elsa AG GLoria Synergy Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (48000ns min, 48000ns max) Interrupt: pin A routed to IRQ 31 Region 0: Memory at 0a20 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at 0900 (32-bit, non-prefetchable) [size=8M] Region 2: Memory at 0980 (32-bit, non-prefetchable) [size=8M] Expansion ROM at 0a23 [disabled] [size=64K] :00:08.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=255 I/O behind bridge: 8000-8fff Memory behind bridge: 0a00-0a0f Prefetchable memory behind bridge: 0a10-0a1f Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- Reset- FastB2B- Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=220mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Bridge: PM- B3+ :01:00.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 04) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (4250ns min, 16000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 27 Region 0: I/O ports at 8000 [size=256] Region 1: Memory at 0a002000 (32-bit, non-prefetchable) [size=256] Region 2: Memory at 0a00 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 0a14 [disabled] [size=64K] :01:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 04) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (4250ns min, 16000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 26 Region
