* RE: Direct I/O to domU seeing a 30% performance hit @ 2006-11-07 12:18 Ian Pratt 2006-11-07 16:44 ` John Byrne 0 siblings, 1 reply; 16+ messages in thread From: Ian Pratt @ 2006-11-07 12:18 UTC (permalink / raw) To: Emmanuel Ackaouy, John Byrne; +Cc: xen-devel > There have been a couple of network receive throughput > performance regressions to domUs over time that were > subsequently fixed. I think one may have crept in to 3.0.3. The report was (I believe) with a NIC directly assigned to the domU, so not using netfront/back at all. John: please can you give more details on your config. Ian > Are you seeing any dropped packets on the vif associated with > your domU in your dom0? If so, propagating changeset > 11861 from unstable may help: > > changeset: 11861:637eace6d5c6 > user: kfraser@localhost.localdomain > date: Mon Oct 23 11:20:37 2006 +0100 > summary: [NET] back: Fix packet queuing so that packets > are drained if the > > > In the past, we also had receive throughput issues to domUs > that were due to socket buffer size logic but those were > fixed a while ago. > > Can you send netstat -i output from dom0? > > Emmanuel. > > > On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > > > I was asked to test direct I/O to a PV domU. Since, I had a system > > with two NICs, I gave one to a domU and one dom0. (Each is > running the > > same > > kernel: xen 3.0.3 x86_64.) > > > > I'm running netperf from an outside system to the domU and > dom0 and I > > am seeing 30% less throughput for the domU vs dom0. > > > > Is this to be expected? If so, why? If not, does anyone > have a guess > > as to what I might be doing wrong or what the issue might be? > > > > Thanks, > > > > John Byrne > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 12:18 Direct I/O to domU seeing a 30% performance hit Ian Pratt @ 2006-11-07 16:44 ` John Byrne 2006-11-07 17:20 ` Ian Pratt 0 siblings, 1 reply; 16+ messages in thread From: John Byrne @ 2006-11-07 16:44 UTC (permalink / raw) To: Ian Pratt; +Cc: xen-devel, Emmanuel Ackaouy [-- Attachment #1: Type: text/plain, Size: 3004 bytes --] Ian, (Sorry. I sent things from the wrong e-mail address, so you've probably been getting bounces. This one should work.) My config is attached, Both dom0 and the domU are SLES 10, so I don't know why the "idle" performance of the two should be different. The obvious asymmetry is the disk. Since the disk isn't direct, any disk I/O by the domU would certainly impact dom0, but I don't think there should be much, if any. I did run a dom0 test with the domU started, but idle and there was no real change to dom0's numbers. What's the best way to gather information about what is going on with the domains without perturbing them? (Or, at least, perturbing everyone equally.) As to the test, I am running netperf 2.4.1 on an outside machine to the dom0 and the domU. (So the doms are running the netserver portion.) I was originally running it in the doms to the outside machine, but when the bad numbers showed up I moved it to the outside machine because I wondered if the bad numbers were due to something happening to the system time in domU. The numbers is the "outside" test to domU look worse. Thanks, John Byrne Ian Pratt wrote: > >> There have been a couple of network receive throughput >> performance regressions to domUs over time that were >> subsequently fixed. I think one may have crept in to 3.0.3. > > The report was (I believe) with a NIC directly assigned to the domU, so > not using netfront/back at all. > > John: please can you give more details on your config. > > Ian > >> Are you seeing any dropped packets on the vif associated with >> your domU in your dom0? If so, propagating changeset >> 11861 from unstable may help: >> >> changeset: 11861:637eace6d5c6 >> user: kfraser@localhost.localdomain >> date: Mon Oct 23 11:20:37 2006 +0100 >> summary: [NET] back: Fix packet queuing so that packets >> are drained if the >> >> >> In the past, we also had receive throughput issues to domUs >> that were due to socket buffer size logic but those were >> fixed a while ago. >> >> Can you send netstat -i output from dom0? >> >> Emmanuel. >> >> >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: >>> I was asked to test direct I/O to a PV domU. Since, I had a system >>> with two NICs, I gave one to a domU and one dom0. (Each is >> running the >>> same >>> kernel: xen 3.0.3 x86_64.) >>> >>> I'm running netperf from an outside system to the domU and >> dom0 and I >>> am seeing 30% less throughput for the domU vs dom0. >>> >>> Is this to be expected? If so, why? If not, does anyone >> have a guess >>> as to what I might be doing wrong or what the issue might be? >>> >>> Thanks, >>> >>> John Byrne >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > [-- Attachment #2: vm1 --] [-- Type: text/plain, Size: 442 bytes --] disk = [ 'file:/disk2/vm1/hda,hda,w' ] memory = 3072 vcpus = 1 builder = 'linux' name = 'vm1' #vif = [ 'mac=00:16:3e:55:0a:86' ] localtime = 0 on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' extra = ' TERM=xterm' #bootloader = '/usr/lib/xen/boot/domUloader.py' #bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen' kernel = '/disk2/vm1/vmlinuz-xen' ramdisk = '/disk2/vm1/initrd-xen' root = '/dev/hda2' pci = [ '05:00.0' ] [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Direct I/O to domU seeing a 30% performance hit 2006-11-07 16:44 ` John Byrne @ 2006-11-07 17:20 ` Ian Pratt 2006-11-07 17:40 ` Performance data of Linux native vs. Xen Dom0 and Xen DomU. " Liang Yang 2006-11-07 19:17 ` John Byrne 0 siblings, 2 replies; 16+ messages in thread From: Ian Pratt @ 2006-11-07 17:20 UTC (permalink / raw) To: John Byrne; +Cc: xen-devel, Emmanuel Ackaouy > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > performance of the two should be different. The obvious asymmetry is the > disk. Since the disk isn't direct, any disk I/O by the domU would > certainly impact dom0, but I don't think there should be much, if any. I > did run a dom0 test with the domU started, but idle and there was no > real change to dom0's numbers. > > What's the best way to gather information about what is going on with > the domains without perturbing them? (Or, at least, perturbing everyone > equally.) > > As to the test, I am running netperf 2.4.1 on an outside machine to the > dom0 and the domU. (So the doms are running the netserver portion.) I > was originally running it in the doms to the outside machine, but when > the bad numbers showed up I moved it to the outside machine because I > wondered if the bad numbers were due to something happening to the > system time in domU. The numbers is the "outside" test to domU look worse. It might be worth checking that there's no interrupt sharing happening. While running the test against the domU, see how much CPU dom0 burns in the same period using 'xm vcpu-list'. To keep things simple, have dom0 and domU as uniprocessor guests. Ian > Ian Pratt wrote: > > > >> There have been a couple of network receive throughput > >> performance regressions to domUs over time that were > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > The report was (I believe) with a NIC directly assigned to the domU, so > > not using netfront/back at all. > > > > John: please can you give more details on your config. > > > > Ian > > > >> Are you seeing any dropped packets on the vif associated with > >> your domU in your dom0? If so, propagating changeset > >> 11861 from unstable may help: > >> > >> changeset: 11861:637eace6d5c6 > >> user: kfraser@localhost.localdomain > >> date: Mon Oct 23 11:20:37 2006 +0100 > >> summary: [NET] back: Fix packet queuing so that packets > >> are drained if the > >> > >> > >> In the past, we also had receive throughput issues to domUs > >> that were due to socket buffer size logic but those were > >> fixed a while ago. > >> > >> Can you send netstat -i output from dom0? > >> > >> Emmanuel. > >> > >> > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > >>> I was asked to test direct I/O to a PV domU. Since, I had a system > >>> with two NICs, I gave one to a domU and one dom0. (Each is > >> running the > >>> same > >>> kernel: xen 3.0.3 x86_64.) > >>> > >>> I'm running netperf from an outside system to the domU and > >> dom0 and I > >>> am seeing 30% less throughput for the domU vs dom0. > >>> > >>> Is this to be expected? If so, why? If not, does anyone > >> have a guess > >>> as to what I might be doing wrong or what the issue might be? > >>> > >>> Thanks, > >>> > >>> John Byrne > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 17:20 ` Ian Pratt @ 2006-11-07 17:40 ` Liang Yang 2006-11-07 18:06 ` Ian Pratt 2006-11-07 19:17 ` John Byrne 1 sibling, 1 reply; 16+ messages in thread From: Liang Yang @ 2006-11-07 17:40 UTC (permalink / raw) To: Ian Pratt, John Byrne; +Cc: xen-devel, Emmanuel Ackaouy Hi Ian and John, I'm also doing some performance analysis about Linux native, dom0 and domU (para-virtualized). Here are some brief comparison for 256K sequential read/write. The testing is done using for JBOD based on 8 Maxtor SAS Atlas 2 15K drives with LSI SAS HBA. 256K Sequential Read Linux Native: 559.6MB/s Xen Domain0: 423.3MB/s Xen DomainU: 555.9MB/s 256K Sequential Write Linux Native: 668.9MB/s Xen Domain0: 708.7MB/s Xen DomainU: 373.5MB/s Just two questions: It seems para-virtualized DomU outperform Dom0 in terms of sequential read and is very to Linux native performance. However, DomU does show poor (only 50%) sequential write performance compared with Linux native and Dom0. Could you explain some reason behind this? Thanks, Liang ----- Original Message ----- From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> To: "John Byrne" <john.l.byrne@hp.com> Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" <ack@xensource.com> Sent: Tuesday, November 07, 2006 10:20 AM Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > performance of the two should be different. The obvious asymmetry is the > disk. Since the disk isn't direct, any disk I/O by the domU would > certainly impact dom0, but I don't think there should be much, if any. I > did run a dom0 test with the domU started, but idle and there was no > real change to dom0's numbers. > > What's the best way to gather information about what is going on with > the domains without perturbing them? (Or, at least, perturbing everyone > equally.) > > As to the test, I am running netperf 2.4.1 on an outside machine to the > dom0 and the domU. (So the doms are running the netserver portion.) I > was originally running it in the doms to the outside machine, but when > the bad numbers showed up I moved it to the outside machine because I > wondered if the bad numbers were due to something happening to the > system time in domU. The numbers is the "outside" test to domU look worse. It might be worth checking that there's no interrupt sharing happening. While running the test against the domU, see how much CPU dom0 burns in the same period using 'xm vcpu-list'. To keep things simple, have dom0 and domU as uniprocessor guests. Ian > Ian Pratt wrote: > > > >> There have been a couple of network receive throughput > >> performance regressions to domUs over time that were > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > The report was (I believe) with a NIC directly assigned to the domU, so > > not using netfront/back at all. > > > > John: please can you give more details on your config. > > > > Ian > > > >> Are you seeing any dropped packets on the vif associated with > >> your domU in your dom0? If so, propagating changeset > >> 11861 from unstable may help: > >> > >> changeset: 11861:637eace6d5c6 > >> user: kfraser@localhost.localdomain > >> date: Mon Oct 23 11:20:37 2006 +0100 > >> summary: [NET] back: Fix packet queuing so that packets > >> are drained if the > >> > >> > >> In the past, we also had receive throughput issues to domUs > >> that were due to socket buffer size logic but those were > >> fixed a while ago. > >> > >> Can you send netstat -i output from dom0? > >> > >> Emmanuel. > >> > >> > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > >>> I was asked to test direct I/O to a PV domU. Since, I had a system > >>> with two NICs, I gave one to a domU and one dom0. (Each is > >> running the > >>> same > >>> kernel: xen 3.0.3 x86_64.) > >>> > >>> I'm running netperf from an outside system to the domU and > >> dom0 and I > >>> am seeing 30% less throughput for the domU vs dom0. > >>> > >>> Is this to be expected? If so, why? If not, does anyone > >> have a guess > >>> as to what I might be doing wrong or what the issue might be? > >>> > >>> Thanks, > >>> > >>> John Byrne > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > >> > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 17:40 ` Performance data of Linux native vs. Xen Dom0 and Xen DomU. " Liang Yang @ 2006-11-07 18:06 ` Ian Pratt 2006-11-07 18:10 ` Liang Yang 2006-11-07 18:14 ` Using IOMeter. " Liang Yang 0 siblings, 2 replies; 16+ messages in thread From: Ian Pratt @ 2006-11-07 18:06 UTC (permalink / raw) To: Liang Yang, John Byrne; +Cc: xen-devel, Emmanuel Ackaouy > I'm also doing some performance analysis about Linux native, dom0 and domU > (para-virtualized). Here are some brief comparison for 256K sequential > read/write. The testing is done using for JBOD based on 8 Maxtor SAS Atlas > 2 > 15K drives with LSI SAS HBA. > > 256K Sequential Read > Linux Native: 559.6MB/s > Xen Domain0: 423.3MB/s > Xen DomainU: 555.9MB/s This doesn't make a lot of sense. Only thing I can think of is that there must be some extra prefetching going on in the domU case. It still doesn't explain why the dom0 result is so much worse than native. It might be worth repeating with both native and dom0 boot with maxcpus=1. Are you using near-identical kernels in both cases? Same drivers, same part of the disk for the tests, etc? How are you doing the measurement? A timed 'dd'? Ian > 256K Sequential Write > Linux Native: 668.9MB/s > Xen Domain0: 708.7MB/s > Xen DomainU: 373.5MB/s > > Just two questions: > > It seems para-virtualized DomU outperform Dom0 in terms of sequential read > and is very to Linux native performance. However, DomU does show poor (only > 50%) sequential write performance compared with Linux native and Dom0. > > Could you explain some reason behind this? > > Thanks, > > Liang > > > ----- Original Message ----- > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > To: "John Byrne" <john.l.byrne@hp.com> > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > <ack@xensource.com> > Sent: Tuesday, November 07, 2006 10:20 AM > Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > > > > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > > performance of the two should be different. The obvious asymmetry is > the > > disk. Since the disk isn't direct, any disk I/O by the domU would > > certainly impact dom0, but I don't think there should be much, if any. > I > > did run a dom0 test with the domU started, but idle and there was no > > real change to dom0's numbers. > > > > What's the best way to gather information about what is going on with > > the domains without perturbing them? (Or, at least, perturbing > everyone > > equally.) > > > > As to the test, I am running netperf 2.4.1 on an outside machine to > the > > dom0 and the domU. (So the doms are running the netserver portion.) I > > was originally running it in the doms to the outside machine, but when > > the bad numbers showed up I moved it to the outside machine because I > > wondered if the bad numbers were due to something happening to the > > system time in domU. The numbers is the "outside" test to domU look > worse. > > > It might be worth checking that there's no interrupt sharing happening. > While running the test against the domU, see how much CPU dom0 burns in > the same period using 'xm vcpu-list'. > > To keep things simple, have dom0 and domU as uniprocessor guests. > > Ian > > > > Ian Pratt wrote: > > > > > >> There have been a couple of network receive throughput > > >> performance regressions to domUs over time that were > > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > > > The report was (I believe) with a NIC directly assigned to the domU, > so > > > not using netfront/back at all. > > > > > > John: please can you give more details on your config. > > > > > > Ian > > > > > >> Are you seeing any dropped packets on the vif associated with > > >> your domU in your dom0? If so, propagating changeset > > >> 11861 from unstable may help: > > >> > > >> changeset: 11861:637eace6d5c6 > > >> user: kfraser@localhost.localdomain > > >> date: Mon Oct 23 11:20:37 2006 +0100 > > >> summary: [NET] back: Fix packet queuing so that packets > > >> are drained if the > > >> > > >> > > >> In the past, we also had receive throughput issues to domUs > > >> that were due to socket buffer size logic but those were > > >> fixed a while ago. > > >> > > >> Can you send netstat -i output from dom0? > > >> > > >> Emmanuel. > > >> > > >> > > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > >>> I was asked to test direct I/O to a PV domU. Since, I had a system > > >>> with two NICs, I gave one to a domU and one dom0. (Each is > > >> running the > > >>> same > > >>> kernel: xen 3.0.3 x86_64.) > > >>> > > >>> I'm running netperf from an outside system to the domU and > > >> dom0 and I > > >>> am seeing 30% less throughput for the domU vs dom0. > > >>> > > >>> Is this to be expected? If so, why? If not, does anyone > > >> have a guess > > >>> as to what I might be doing wrong or what the issue might be? > > >>> > > >>> Thanks, > > >>> > > >>> John Byrne > > >> _______________________________________________ > > >> Xen-devel mailing list > > >> Xen-devel@lists.xensource.com > > >> http://lists.xensource.com/xen-devel > > >> > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 18:06 ` Ian Pratt @ 2006-11-07 18:10 ` Liang Yang 2006-11-07 18:15 ` Ian Pratt 2006-11-07 18:14 ` Using IOMeter. " Liang Yang 1 sibling, 1 reply; 16+ messages in thread From: Liang Yang @ 2006-11-07 18:10 UTC (permalink / raw) To: Ian Pratt, John Byrne; +Cc: xen-devel, Emmanuel Ackaouy Hi Ian, I already set dom0_max_vcpus=1 for domain0 when I was doing testing. Also, Linux native kernel and domU kernel are all compiled as Uni-Processor mode.All the testing for Linux native, domain0 and domainU are exactly the same. All used Linux kernel 2.6.16.29. Regards, Liang ----- Original Message ----- From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> To: "Liang Yang" <multisyncfe991@hotmail.com>; "John Byrne" <john.l.byrne@hp.com> Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> Sent: Tuesday, November 07, 2006 11:06 AM Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > I'm also doing some performance analysis about Linux native, dom0 and domU > (para-virtualized). Here are some brief comparison for 256K sequential > read/write. The testing is done using for JBOD based on 8 Maxtor SAS Atlas > 2 > 15K drives with LSI SAS HBA. > > 256K Sequential Read > Linux Native: 559.6MB/s > Xen Domain0: 423.3MB/s > Xen DomainU: 555.9MB/s This doesn't make a lot of sense. Only thing I can think of is that there must be some extra prefetching going on in the domU case. It still doesn't explain why the dom0 result is so much worse than native. It might be worth repeating with both native and dom0 boot with maxcpus=1. Are you using near-identical kernels in both cases? Same drivers, same part of the disk for the tests, etc? How are you doing the measurement? A timed 'dd'? Ian > 256K Sequential Write > Linux Native: 668.9MB/s > Xen Domain0: 708.7MB/s > Xen DomainU: 373.5MB/s > > Just two questions: > > It seems para-virtualized DomU outperform Dom0 in terms of sequential read > and is very to Linux native performance. However, DomU does show poor (only > 50%) sequential write performance compared with Linux native and Dom0. > > Could you explain some reason behind this? > > Thanks, > > Liang > > > ----- Original Message ----- > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > To: "John Byrne" <john.l.byrne@hp.com> > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > <ack@xensource.com> > Sent: Tuesday, November 07, 2006 10:20 AM > Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > > > > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > > performance of the two should be different. The obvious asymmetry is > the > > disk. Since the disk isn't direct, any disk I/O by the domU would > > certainly impact dom0, but I don't think there should be much, if any. > I > > did run a dom0 test with the domU started, but idle and there was no > > real change to dom0's numbers. > > > > What's the best way to gather information about what is going on with > > the domains without perturbing them? (Or, at least, perturbing > everyone > > equally.) > > > > As to the test, I am running netperf 2.4.1 on an outside machine to > the > > dom0 and the domU. (So the doms are running the netserver portion.) I > > was originally running it in the doms to the outside machine, but when > > the bad numbers showed up I moved it to the outside machine because I > > wondered if the bad numbers were due to something happening to the > > system time in domU. The numbers is the "outside" test to domU look > worse. > > > It might be worth checking that there's no interrupt sharing happening. > While running the test against the domU, see how much CPU dom0 burns in > the same period using 'xm vcpu-list'. > > To keep things simple, have dom0 and domU as uniprocessor guests. > > Ian > > > > Ian Pratt wrote: > > > > > >> There have been a couple of network receive throughput > > >> performance regressions to domUs over time that were > > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > > > The report was (I believe) with a NIC directly assigned to the domU, > so > > > not using netfront/back at all. > > > > > > John: please can you give more details on your config. > > > > > > Ian > > > > > >> Are you seeing any dropped packets on the vif associated with > > >> your domU in your dom0? If so, propagating changeset > > >> 11861 from unstable may help: > > >> > > >> changeset: 11861:637eace6d5c6 > > >> user: kfraser@localhost.localdomain > > >> date: Mon Oct 23 11:20:37 2006 +0100 > > >> summary: [NET] back: Fix packet queuing so that packets > > >> are drained if the > > >> > > >> > > >> In the past, we also had receive throughput issues to domUs > > >> that were due to socket buffer size logic but those were > > >> fixed a while ago. > > >> > > >> Can you send netstat -i output from dom0? > > >> > > >> Emmanuel. > > >> > > >> > > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > >>> I was asked to test direct I/O to a PV domU. Since, I had a system > > >>> with two NICs, I gave one to a domU and one dom0. (Each is > > >> running the > > >>> same > > >>> kernel: xen 3.0.3 x86_64.) > > >>> > > >>> I'm running netperf from an outside system to the domU and > > >> dom0 and I > > >>> am seeing 30% less throughput for the domU vs dom0. > > >>> > > >>> Is this to be expected? If so, why? If not, does anyone > > >> have a guess > > >>> as to what I might be doing wrong or what the issue might be? > > >>> > > >>> Thanks, > > >>> > > >>> John Byrne > > >> _______________________________________________ > > >> Xen-devel mailing list > > >> Xen-devel@lists.xensource.com > > >> http://lists.xensource.com/xen-devel > > >> > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 18:10 ` Liang Yang @ 2006-11-07 18:15 ` Ian Pratt 2006-11-07 18:23 ` Liang Yang 0 siblings, 1 reply; 16+ messages in thread From: Ian Pratt @ 2006-11-07 18:15 UTC (permalink / raw) To: Liang Yang, John Byrne; +Cc: xen-devel, Emmanuel Ackaouy > I already set dom0_max_vcpus=1 for domain0 when I was doing testing. Also, > Linux native kernel and domU kernel are all compiled as Uni-Processor > mode.All the testing for Linux native, domain0 and domainU are exactly the > same. All used Linux kernel 2.6.16.29. Please could you post a 'diff' of the two kernel configs. It might be worth diff'ing the boot messages in both cases too. Thanks, Ian > Regards, > > Liang > > ----- Original Message ----- > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > To: "Liang Yang" <multisyncfe991@hotmail.com>; "John Byrne" > <john.l.byrne@hp.com> > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> > Sent: Tuesday, November 07, 2006 11:06 AM > Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. > Re: > [Xen-devel] Direct I/O to domU seeing a 30% performance hit > > > > I'm also doing some performance analysis about Linux native, dom0 and > domU > > (para-virtualized). Here are some brief comparison for 256K sequential > > read/write. The testing is done using for JBOD based on 8 Maxtor SAS > Atlas > > 2 > > 15K drives with LSI SAS HBA. > > > > 256K Sequential Read > > Linux Native: 559.6MB/s > > Xen Domain0: 423.3MB/s > > Xen DomainU: 555.9MB/s > > This doesn't make a lot of sense. Only thing I can think of is that > there must be some extra prefetching going on in the domU case. It still > doesn't explain why the dom0 result is so much worse than native. > > It might be worth repeating with both native and dom0 boot with > maxcpus=1. > > Are you using near-identical kernels in both cases? Same drivers, same > part of the disk for the tests, etc? > > How are you doing the measurement? A timed 'dd'? > > Ian > > > > 256K Sequential Write > > Linux Native: 668.9MB/s > > Xen Domain0: 708.7MB/s > > Xen DomainU: 373.5MB/s > > > > Just two questions: > > > > It seems para-virtualized DomU outperform Dom0 in terms of sequential > read > > and is very to Linux native performance. However, DomU does show poor > (only > > 50%) sequential write performance compared with Linux native and Dom0. > > > > Could you explain some reason behind this? > > > > Thanks, > > > > Liang > > > > > > ----- Original Message ----- > > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > > To: "John Byrne" <john.l.byrne@hp.com> > > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > > <ack@xensource.com> > > Sent: Tuesday, November 07, 2006 10:20 AM > > Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance > hit > > > > > > > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > > > performance of the two should be different. The obvious asymmetry is > > the > > > disk. Since the disk isn't direct, any disk I/O by the domU would > > > certainly impact dom0, but I don't think there should be much, if > any. > > I > > > did run a dom0 test with the domU started, but idle and there was no > > > real change to dom0's numbers. > > > > > > What's the best way to gather information about what is going on > with > > > the domains without perturbing them? (Or, at least, perturbing > > everyone > > > equally.) > > > > > > As to the test, I am running netperf 2.4.1 on an outside machine to > > the > > > dom0 and the domU. (So the doms are running the netserver portion.) > I > > > was originally running it in the doms to the outside machine, but > when > > > the bad numbers showed up I moved it to the outside machine because > I > > > wondered if the bad numbers were due to something happening to the > > > system time in domU. The numbers is the "outside" test to domU look > > worse. > > > > > > It might be worth checking that there's no interrupt sharing > happening. > > While running the test against the domU, see how much CPU dom0 burns > in > > the same period using 'xm vcpu-list'. > > > > To keep things simple, have dom0 and domU as uniprocessor guests. > > > > Ian > > > > > > > Ian Pratt wrote: > > > > > > > >> There have been a couple of network receive throughput > > > >> performance regressions to domUs over time that were > > > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > > > > > The report was (I believe) with a NIC directly assigned to the > domU, > > so > > > > not using netfront/back at all. > > > > > > > > John: please can you give more details on your config. > > > > > > > > Ian > > > > > > > >> Are you seeing any dropped packets on the vif associated with > > > >> your domU in your dom0? If so, propagating changeset > > > >> 11861 from unstable may help: > > > >> > > > >> changeset: 11861:637eace6d5c6 > > > >> user: kfraser@localhost.localdomain > > > >> date: Mon Oct 23 11:20:37 2006 +0100 > > > >> summary: [NET] back: Fix packet queuing so that packets > > > >> are drained if the > > > >> > > > >> > > > >> In the past, we also had receive throughput issues to domUs > > > >> that were due to socket buffer size logic but those were > > > >> fixed a while ago. > > > >> > > > >> Can you send netstat -i output from dom0? > > > >> > > > >> Emmanuel. > > > >> > > > >> > > > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > > >>> I was asked to test direct I/O to a PV domU. Since, I had a > system > > > >>> with two NICs, I gave one to a domU and one dom0. (Each is > > > >> running the > > > >>> same > > > >>> kernel: xen 3.0.3 x86_64.) > > > >>> > > > >>> I'm running netperf from an outside system to the domU and > > > >> dom0 and I > > > >>> am seeing 30% less throughput for the domU vs dom0. > > > >>> > > > >>> Is this to be expected? If so, why? If not, does anyone > > > >> have a guess > > > >>> as to what I might be doing wrong or what the issue might be? > > > >>> > > > >>> Thanks, > > > >>> > > > >>> John Byrne > > > >> _______________________________________________ > > > >> Xen-devel mailing list > > > >> Xen-devel@lists.xensource.com > > > >> http://lists.xensource.com/xen-devel > > > >> > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xensource.com > > > > http://lists.xensource.com/xen-devel > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 18:15 ` Ian Pratt @ 2006-11-07 18:23 ` Liang Yang 2006-11-07 18:40 ` George Dunlap 0 siblings, 1 reply; 16+ messages in thread From: Liang Yang @ 2006-11-07 18:23 UTC (permalink / raw) To: Ian Pratt, John Byrne; +Cc: xen-devel, Emmanuel Ackaouy [-- Attachment #1: Type: text/plain, Size: 6859 bytes --] Attached is the diff of the two kernel configs. ----- Original Message ----- From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> To: "Liang Yang" <yangliang_mr@hotmail.com>; "John Byrne" <john.l.byrne@hp.com> Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> Sent: Tuesday, November 07, 2006 11:15 AM Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > I already set dom0_max_vcpus=1 for domain0 when I was doing testing. Also, > Linux native kernel and domU kernel are all compiled as Uni-Processor > mode.All the testing for Linux native, domain0 and domainU are exactly the > same. All used Linux kernel 2.6.16.29. Please could you post a 'diff' of the two kernel configs. It might be worth diff'ing the boot messages in both cases too. Thanks, Ian > Regards, > > Liang > > ----- Original Message ----- > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > To: "Liang Yang" <multisyncfe991@hotmail.com>; "John Byrne" > <john.l.byrne@hp.com> > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> > Sent: Tuesday, November 07, 2006 11:06 AM > Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. > Re: > [Xen-devel] Direct I/O to domU seeing a 30% performance hit > > > > I'm also doing some performance analysis about Linux native, dom0 and > domU > > (para-virtualized). Here are some brief comparison for 256K sequential > > read/write. The testing is done using for JBOD based on 8 Maxtor SAS > Atlas > > 2 > > 15K drives with LSI SAS HBA. > > > > 256K Sequential Read > > Linux Native: 559.6MB/s > > Xen Domain0: 423.3MB/s > > Xen DomainU: 555.9MB/s > > This doesn't make a lot of sense. Only thing I can think of is that > there must be some extra prefetching going on in the domU case. It still > doesn't explain why the dom0 result is so much worse than native. > > It might be worth repeating with both native and dom0 boot with > maxcpus=1. > > Are you using near-identical kernels in both cases? Same drivers, same > part of the disk for the tests, etc? > > How are you doing the measurement? A timed 'dd'? > > Ian > > > > 256K Sequential Write > > Linux Native: 668.9MB/s > > Xen Domain0: 708.7MB/s > > Xen DomainU: 373.5MB/s > > > > Just two questions: > > > > It seems para-virtualized DomU outperform Dom0 in terms of sequential > read > > and is very to Linux native performance. However, DomU does show poor > (only > > 50%) sequential write performance compared with Linux native and Dom0. > > > > Could you explain some reason behind this? > > > > Thanks, > > > > Liang > > > > > > ----- Original Message ----- > > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > > To: "John Byrne" <john.l.byrne@hp.com> > > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > > <ack@xensource.com> > > Sent: Tuesday, November 07, 2006 10:20 AM > > Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance > hit > > > > > > > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > > > performance of the two should be different. The obvious asymmetry is > > the > > > disk. Since the disk isn't direct, any disk I/O by the domU would > > > certainly impact dom0, but I don't think there should be much, if > any. > > I > > > did run a dom0 test with the domU started, but idle and there was no > > > real change to dom0's numbers. > > > > > > What's the best way to gather information about what is going on > with > > > the domains without perturbing them? (Or, at least, perturbing > > everyone > > > equally.) > > > > > > As to the test, I am running netperf 2.4.1 on an outside machine to > > the > > > dom0 and the domU. (So the doms are running the netserver portion.) > I > > > was originally running it in the doms to the outside machine, but > when > > > the bad numbers showed up I moved it to the outside machine because > I > > > wondered if the bad numbers were due to something happening to the > > > system time in domU. The numbers is the "outside" test to domU look > > worse. > > > > > > It might be worth checking that there's no interrupt sharing > happening. > > While running the test against the domU, see how much CPU dom0 burns > in > > the same period using 'xm vcpu-list'. > > > > To keep things simple, have dom0 and domU as uniprocessor guests. > > > > Ian > > > > > > > Ian Pratt wrote: > > > > > > > >> There have been a couple of network receive throughput > > > >> performance regressions to domUs over time that were > > > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > > > > > The report was (I believe) with a NIC directly assigned to the > domU, > > so > > > > not using netfront/back at all. > > > > > > > > John: please can you give more details on your config. > > > > > > > > Ian > > > > > > > >> Are you seeing any dropped packets on the vif associated with > > > >> your domU in your dom0? If so, propagating changeset > > > >> 11861 from unstable may help: > > > >> > > > >> changeset: 11861:637eace6d5c6 > > > >> user: kfraser@localhost.localdomain > > > >> date: Mon Oct 23 11:20:37 2006 +0100 > > > >> summary: [NET] back: Fix packet queuing so that packets > > > >> are drained if the > > > >> > > > >> > > > >> In the past, we also had receive throughput issues to domUs > > > >> that were due to socket buffer size logic but those were > > > >> fixed a while ago. > > > >> > > > >> Can you send netstat -i output from dom0? > > > >> > > > >> Emmanuel. > > > >> > > > >> > > > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > > >>> I was asked to test direct I/O to a PV domU. Since, I had a > system > > > >>> with two NICs, I gave one to a domU and one dom0. (Each is > > > >> running the > > > >>> same > > > >>> kernel: xen 3.0.3 x86_64.) > > > >>> > > > >>> I'm running netperf from an outside system to the domU and > > > >> dom0 and I > > > >>> am seeing 30% less throughput for the domU vs dom0. > > > >>> > > > >>> Is this to be expected? If so, why? If not, does anyone > > > >> have a guess > > > >>> as to what I might be doing wrong or what the issue might be? > > > >>> > > > >>> Thanks, > > > >>> > > > >>> John Byrne > > > >> _______________________________________________ > > > >> Xen-devel mailing list > > > >> Xen-devel@lists.xensource.com > > > >> http://lists.xensource.com/xen-devel > > > >> > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xensource.com > > > > http://lists.xensource.com/xen-devel > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > [-- Attachment #2: kernel.diff --] [-- Type: application/octet-stream, Size: 59220 bytes --] 3,4c3,4 < # Linux kernel version: 2.6.16.29-xen < # Mon Nov 6 11:07:43 2006 --- > # Linux kernel version: 2.6.16.29 > # Mon Nov 6 15:50:49 2006 19c19 < CONFIG_LOCK_KERNEL=y --- > CONFIG_BROKEN_ON_SMP=y 26c26 < # CONFIG_LOCALVERSION_AUTO is not set --- > CONFIG_LOCALVERSION_AUTO=y 31c31 < CONFIG_BSD_PROCESS_ACCT_V3=y --- > # CONFIG_BSD_PROCESS_ACCT_V3 is not set 35,37c35 < CONFIG_IKCONFIG=y < CONFIG_IKCONFIG_PROC=y < CONFIG_CPUSETS=y --- > # CONFIG_IKCONFIG is not set 41c39 < # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set --- > CONFIG_CC_OPTIMIZE_FOR_SIZE=y 45c43 < # CONFIG_KALLSYMS_EXTRA_PASS is not set --- > CONFIG_KALLSYMS_EXTRA_PASS=y 69c67 < CONFIG_MODULE_FORCE_UNLOAD=y --- > # CONFIG_MODULE_FORCE_UNLOAD is not set 72c70 < CONFIG_MODULE_SRCVERSION_ALL=y --- > # CONFIG_MODULE_SRCVERSION_ALL is not set 74d71 < CONFIG_STOP_MACHINE=y 88c85 < # CONFIG_DEFAULT_AS is not set --- > CONFIG_DEFAULT_AS=y 90c87 < CONFIG_DEFAULT_CFQ=y --- > # CONFIG_DEFAULT_CFQ is not set 92c89 < CONFIG_DEFAULT_IOSCHED="cfq" --- > CONFIG_DEFAULT_IOSCHED="anticipatory" 97,98c94 < # CONFIG_X86_PC is not set < CONFIG_X86_XEN=y --- > CONFIG_X86_PC=y 112c108 < CONFIG_M686=y --- > # CONFIG_M686 is not set 116c112 < # CONFIG_MPENTIUM4 is not set --- > CONFIG_MPENTIUM4=y 135d130 < CONFIG_X86_PPRO_FENCE=y 145,147c140,142 < CONFIG_SMP=y < CONFIG_SMP_ALTERNATIVES=y < CONFIG_NR_CPUS=32 --- > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > # CONFIG_SMP is not set 151c146,147 < CONFIG_PREEMPT_BKL=y --- > CONFIG_X86_UP_APIC=y > CONFIG_X86_UP_IOAPIC=y 154,155c150,154 < # CONFIG_TOSHIBA is not set < # CONFIG_I8K is not set --- > CONFIG_X86_MCE=y > # CONFIG_X86_MCE_NONFATAL is not set > CONFIG_X86_MCE_P4THERMAL=y > CONFIG_TOSHIBA=m > CONFIG_I8K=m 157c156,157 < CONFIG_MICROCODE=y --- > CONFIG_MICROCODE=m > CONFIG_X86_MSR=m 159d158 < CONFIG_SWIOTLB=y 163a163 > CONFIG_EDD=m 174a175,177 > CONFIG_ARCH_FLATMEM_ENABLE=y > CONFIG_ARCH_SPARSEMEM_ENABLE=y > CONFIG_ARCH_SELECT_MEMORY_MODEL=y 181,182c184,187 < # CONFIG_SPARSEMEM_STATIC is not set < CONFIG_SPLIT_PTLOCK_CPUS=4096 --- > CONFIG_SPARSEMEM_STATIC=y > CONFIG_SPLIT_PTLOCK_CPUS=4 > CONFIG_HIGHPTE=y > # CONFIG_MATH_EMULATION is not set 183a189 > # CONFIG_EFI is not set 186,187c192,193 < CONFIG_HZ_100=y < # CONFIG_HZ_250 is not set --- > # CONFIG_HZ_100 is not set > CONFIG_HZ_250=y 189c195,196 < CONFIG_HZ=100 --- > CONFIG_HZ=250 > # CONFIG_KEXEC is not set 192c199 < CONFIG_HOTPLUG_CPU=y --- > CONFIG_DOUBLEFAULT=y 198a206,208 > CONFIG_PM_LEGACY=y > # CONFIG_PM_DEBUG is not set > # CONFIG_SOFTWARE_SUSPEND is not set 203a214,216 > CONFIG_ACPI_SLEEP=y > CONFIG_ACPI_SLEEP_PROC_FS=y > # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set 207,212c220,224 < CONFIG_ACPI_VIDEO=m < CONFIG_ACPI_HOTKEY=m < CONFIG_ACPI_FAN=m < CONFIG_ACPI_PROCESSOR=m < CONFIG_ACPI_HOTPLUG_CPU=y < CONFIG_ACPI_THERMAL=m --- > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_HOTKEY is not set > CONFIG_ACPI_FAN=y > CONFIG_ACPI_PROCESSOR=y > CONFIG_ACPI_THERMAL=y 214c226 < CONFIG_ACPI_IBM=m --- > # CONFIG_ACPI_IBM is not set 216c228 < CONFIG_ACPI_BLACKLIST_YEAR=0 --- > CONFIG_ACPI_BLACKLIST_YEAR=2001 221c233,246 < CONFIG_ACPI_CONTAINER=m --- > CONFIG_X86_PM_TIMER=y > # CONFIG_ACPI_CONTAINER is not set > > # > # APM (Advanced Power Management) BIOS Support > # > CONFIG_APM=y > # CONFIG_APM_IGNORE_USER_SUSPEND is not set > # CONFIG_APM_DO_ENABLE is not set > CONFIG_APM_CPU_IDLE=y > # CONFIG_APM_DISPLAY_BLANK is not set > CONFIG_APM_RTC_IS_GMT=y > # CONFIG_APM_ALLOW_INTS is not set > # CONFIG_APM_REAL_MODE_POWER_OFF is not set 226c251,288 < # CONFIG_CPU_FREQ is not set --- > CONFIG_CPU_FREQ=y > CONFIG_CPU_FREQ_TABLE=y > # CONFIG_CPU_FREQ_DEBUG is not set > CONFIG_CPU_FREQ_STAT=y > # CONFIG_CPU_FREQ_STAT_DETAILS is not set > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > CONFIG_CPU_FREQ_GOV_USERSPACE=y > CONFIG_CPU_FREQ_GOV_ONDEMAND=m > # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set > > # > # CPUFreq processor drivers > # > CONFIG_X86_ACPI_CPUFREQ=y > CONFIG_X86_POWERNOW_K6=m > CONFIG_X86_POWERNOW_K7=y > CONFIG_X86_POWERNOW_K7_ACPI=y > CONFIG_X86_POWERNOW_K8=m > CONFIG_X86_POWERNOW_K8_ACPI=y > # CONFIG_X86_GX_SUSPMOD is not set > CONFIG_X86_SPEEDSTEP_CENTRINO=y > CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y > CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y > CONFIG_X86_SPEEDSTEP_ICH=y > CONFIG_X86_SPEEDSTEP_SMI=m > CONFIG_X86_P4_CLOCKMOD=m > # CONFIG_X86_CPUFREQ_NFORCE2 is not set > CONFIG_X86_LONGRUN=y > > # > # shared options > # > # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set > CONFIG_X86_SPEEDSTEP_LIB=y > # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set 235d296 < # CONFIG_PCI_GOXEN_FE is not set 236a298 > CONFIG_PCI_BIOS=y 239,240d300 < CONFIG_XEN_PCIDEV_FRONTEND=y < # CONFIG_XEN_PCIDEV_FE_DEBUG is not set 242c302,303 < # CONFIG_PCI_LEGACY_PROC is not set --- > CONFIG_PCI_MSI=y > CONFIG_PCI_LEGACY_PROC=y 245c306,309 < CONFIG_SCx200=m --- > CONFIG_ISA=y > # CONFIG_EISA is not set > # CONFIG_MCA is not set > # CONFIG_SCx200 is not set 250,268c314 < CONFIG_PCCARD=m < # CONFIG_PCMCIA_DEBUG is not set < CONFIG_PCMCIA=m < CONFIG_PCMCIA_LOAD_CIS=y < CONFIG_PCMCIA_IOCTL=y < CONFIG_CARDBUS=y < < # < # PC-card bridges < # < CONFIG_YENTA=m < CONFIG_YENTA_O2=y < CONFIG_YENTA_RICOH=y < CONFIG_YENTA_TI=y < CONFIG_YENTA_ENE_TUNE=y < CONFIG_YENTA_TOSHIBA=y < CONFIG_PD6729=m < CONFIG_I82092=m < CONFIG_PCCARD_NONSTATIC=m --- > # CONFIG_PCCARD is not set 273,274c319,323 < CONFIG_HOTPLUG_PCI=m < CONFIG_HOTPLUG_PCI_FAKE=m --- > CONFIG_HOTPLUG_PCI=y > # CONFIG_HOTPLUG_PCI_FAKE is not set > CONFIG_HOTPLUG_PCI_COMPAQ=m > # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set > CONFIG_HOTPLUG_PCI_IBM=m 277,279c326 < CONFIG_HOTPLUG_PCI_CPCI=y < CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m < CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m --- > # CONFIG_HOTPLUG_PCI_CPCI is not set 287,288c334,335 < CONFIG_BINFMT_AOUT=m < CONFIG_BINFMT_MISC=m --- > # CONFIG_BINFMT_AOUT is not set > CONFIG_BINFMT_MISC=y 303c350 < CONFIG_XFRM_USER=m --- > CONFIG_XFRM_USER=y 329,343c376,379 < CONFIG_INET_DIAG=m < CONFIG_INET_TCP_DIAG=m < CONFIG_TCP_CONG_ADVANCED=y < < # < # TCP congestion control < # < CONFIG_TCP_CONG_BIC=m < CONFIG_TCP_CONG_CUBIC=m < CONFIG_TCP_CONG_WESTWOOD=m < CONFIG_TCP_CONG_HTCP=m < CONFIG_TCP_CONG_HSTCP=m < CONFIG_TCP_CONG_HYBLA=m < CONFIG_TCP_CONG_VEGAS=m < CONFIG_TCP_CONG_SCALABLE=m --- > CONFIG_INET_DIAG=y > CONFIG_INET_TCP_DIAG=y > # CONFIG_TCP_CONG_ADVANCED is not set > CONFIG_TCP_CONG_BIC=y 392,417c428,429 < CONFIG_NETFILTER_NETLINK=m < CONFIG_NETFILTER_NETLINK_QUEUE=m < CONFIG_NETFILTER_NETLINK_LOG=m < CONFIG_NETFILTER_XTABLES=m < CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m < CONFIG_NETFILTER_XT_TARGET_CONNMARK=m < CONFIG_NETFILTER_XT_TARGET_MARK=m < CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m < CONFIG_NETFILTER_XT_TARGET_NOTRACK=m < CONFIG_NETFILTER_XT_MATCH_COMMENT=m < CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m < CONFIG_NETFILTER_XT_MATCH_CONNMARK=m < CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m < CONFIG_NETFILTER_XT_MATCH_DCCP=m < CONFIG_NETFILTER_XT_MATCH_HELPER=m < CONFIG_NETFILTER_XT_MATCH_LENGTH=m < CONFIG_NETFILTER_XT_MATCH_LIMIT=m < CONFIG_NETFILTER_XT_MATCH_MAC=m < CONFIG_NETFILTER_XT_MATCH_MARK=m < CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m < CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m < CONFIG_NETFILTER_XT_MATCH_REALM=m < CONFIG_NETFILTER_XT_MATCH_SCTP=m < CONFIG_NETFILTER_XT_MATCH_STATE=m < CONFIG_NETFILTER_XT_MATCH_STRING=m < CONFIG_NETFILTER_XT_MATCH_TCPMSS=m --- > # CONFIG_NETFILTER_NETLINK is not set > # CONFIG_NETFILTER_XTABLES is not set 424,426c436,437 < CONFIG_IP_NF_CONNTRACK_MARK=y < CONFIG_IP_NF_CONNTRACK_EVENTS=y < CONFIG_IP_NF_CONNTRACK_NETLINK=m --- > # CONFIG_IP_NF_CONNTRACK_MARK is not set > # CONFIG_IP_NF_CONNTRACK_EVENTS is not set 430c441 < CONFIG_IP_NF_NETBIOS_NS=m --- > # CONFIG_IP_NF_NETBIOS_NS is not set 433c444 < CONFIG_IP_NF_PPTP=m --- > # CONFIG_IP_NF_PPTP is not set 435,474d445 < CONFIG_IP_NF_IPTABLES=m < CONFIG_IP_NF_MATCH_IPRANGE=m < CONFIG_IP_NF_MATCH_MULTIPORT=m < CONFIG_IP_NF_MATCH_TOS=m < CONFIG_IP_NF_MATCH_RECENT=m < CONFIG_IP_NF_MATCH_ECN=m < CONFIG_IP_NF_MATCH_DSCP=m < CONFIG_IP_NF_MATCH_AH_ESP=m < CONFIG_IP_NF_MATCH_TTL=m < CONFIG_IP_NF_MATCH_OWNER=m < CONFIG_IP_NF_MATCH_ADDRTYPE=m < CONFIG_IP_NF_MATCH_HASHLIMIT=m < CONFIG_IP_NF_MATCH_POLICY=m < CONFIG_IP_NF_FILTER=m < CONFIG_IP_NF_TARGET_REJECT=m < CONFIG_IP_NF_TARGET_LOG=m < CONFIG_IP_NF_TARGET_ULOG=m < CONFIG_IP_NF_TARGET_TCPMSS=m < CONFIG_IP_NF_NAT=m < CONFIG_IP_NF_NAT_NEEDED=y < CONFIG_IP_NF_TARGET_MASQUERADE=m < CONFIG_IP_NF_TARGET_REDIRECT=m < CONFIG_IP_NF_TARGET_NETMAP=m < CONFIG_IP_NF_TARGET_SAME=m < CONFIG_IP_NF_NAT_SNMP_BASIC=m < CONFIG_IP_NF_NAT_IRC=m < CONFIG_IP_NF_NAT_FTP=m < CONFIG_IP_NF_NAT_TFTP=m < CONFIG_IP_NF_NAT_AMANDA=m < CONFIG_IP_NF_NAT_PPTP=m < CONFIG_IP_NF_MANGLE=m < CONFIG_IP_NF_TARGET_TOS=m < CONFIG_IP_NF_TARGET_ECN=m < CONFIG_IP_NF_TARGET_DSCP=m < CONFIG_IP_NF_TARGET_TTL=m < CONFIG_IP_NF_TARGET_CLUSTERIP=m < CONFIG_IP_NF_RAW=m < CONFIG_IP_NF_ARPTABLES=m < CONFIG_IP_NF_ARPFILTER=m < CONFIG_IP_NF_ARP_MANGLE=m 479,501c450 < CONFIG_IP6_NF_QUEUE=m < CONFIG_IP6_NF_IPTABLES=m < CONFIG_IP6_NF_MATCH_RT=m < CONFIG_IP6_NF_MATCH_OPTS=m < CONFIG_IP6_NF_MATCH_FRAG=m < CONFIG_IP6_NF_MATCH_HL=m < CONFIG_IP6_NF_MATCH_MULTIPORT=m < CONFIG_IP6_NF_MATCH_OWNER=m < CONFIG_IP6_NF_MATCH_IPV6HEADER=m < CONFIG_IP6_NF_MATCH_AHESP=m < CONFIG_IP6_NF_MATCH_EUI64=m < CONFIG_IP6_NF_MATCH_POLICY=m < CONFIG_IP6_NF_FILTER=m < CONFIG_IP6_NF_TARGET_LOG=m < CONFIG_IP6_NF_TARGET_REJECT=m < CONFIG_IP6_NF_MANGLE=m < CONFIG_IP6_NF_TARGET_HL=m < CONFIG_IP6_NF_RAW=m < < # < # DECnet: Netfilter Configuration < # < CONFIG_DECNET_NF_GRABULATOR=m --- > # CONFIG_IP6_NF_QUEUE is not set 525c474 < CONFIG_BRIDGE_EBT_ULOG=m --- > # CONFIG_BRIDGE_EBT_ULOG is not set 530,543c479 < CONFIG_IP_DCCP=m < CONFIG_INET_DCCP_DIAG=m < < # < # DCCP CCIDs Configuration (EXPERIMENTAL) < # < CONFIG_IP_DCCP_CCID3=m < CONFIG_IP_DCCP_TFRC_LIB=m < < # < # DCCP Kernel Hacking < # < # CONFIG_IP_DCCP_DEBUG is not set < # CONFIG_IP_DCCP_UNLOAD_HACK is not set --- > # CONFIG_IP_DCCP is not set 561c497 < CONFIG_ATM_CLIP_NO_ICMP=y --- > # CONFIG_ATM_CLIP_NO_ICMP is not set 563c499 < CONFIG_ATM_MPOA=m --- > # CONFIG_ATM_MPOA is not set 568,570c504 < CONFIG_DECNET=m < CONFIG_DECNET_ROUTER=y < CONFIG_DECNET_ROUTE_FWMARK=y --- > # CONFIG_DECNET is not set 572,586c506,513 < CONFIG_LLC2=m < CONFIG_IPX=m < # CONFIG_IPX_INTERN is not set < CONFIG_ATALK=m < CONFIG_DEV_APPLETALK=y < CONFIG_IPDDP=m < CONFIG_IPDDP_ENCAP=y < CONFIG_IPDDP_DECAP=y < CONFIG_X25=m < CONFIG_LAPB=m < # CONFIG_NET_DIVERT is not set < CONFIG_ECONET=m < CONFIG_ECONET_AUNUDP=y < CONFIG_ECONET_NATIVE=y < CONFIG_WAN_ROUTER=m --- > # CONFIG_LLC2 is not set > # CONFIG_IPX is not set > # CONFIG_ATALK is not set > # CONFIG_X25 is not set > # CONFIG_LAPB is not set > CONFIG_NET_DIVERT=y > # CONFIG_ECONET is not set > # CONFIG_WAN_ROUTER is not set 617c544 < CONFIG_NET_CLS_BASIC=m --- > # CONFIG_NET_CLS_BASIC is not set 624c551 < CONFIG_CLS_U32_MARK=y --- > # CONFIG_CLS_U32_MARK is not set 627,633c554 < CONFIG_NET_EMATCH=y < CONFIG_NET_EMATCH_STACK=32 < CONFIG_NET_EMATCH_CMP=m < CONFIG_NET_EMATCH_NBYTE=m < CONFIG_NET_EMATCH_U32=m < CONFIG_NET_EMATCH_META=m < CONFIG_NET_EMATCH_TEXT=m --- > # CONFIG_NET_EMATCH is not set 636c557 < # CONFIG_NET_CLS_IND is not set --- > CONFIG_NET_CLS_IND=y 642,723c563,565 < CONFIG_NET_PKTGEN=m < CONFIG_HAMRADIO=y < < # < # Packet Radio protocols < # < CONFIG_AX25=m < # CONFIG_AX25_DAMA_SLAVE is not set < CONFIG_NETROM=m < CONFIG_ROSE=m < < # < # AX.25 network device drivers < # < CONFIG_MKISS=m < CONFIG_6PACK=m < CONFIG_BPQETHER=m < CONFIG_BAYCOM_SER_FDX=m < CONFIG_BAYCOM_SER_HDX=m < CONFIG_BAYCOM_PAR=m < CONFIG_BAYCOM_EPP=m < CONFIG_YAM=m < CONFIG_IRDA=m < < # < # IrDA protocols < # < CONFIG_IRLAN=m < CONFIG_IRNET=m < CONFIG_IRCOMM=m < # CONFIG_IRDA_ULTRA is not set < < # < # IrDA options < # < CONFIG_IRDA_CACHE_LAST_LSAP=y < CONFIG_IRDA_FAST_RR=y < CONFIG_IRDA_DEBUG=y < < # < # Infrared-port device drivers < # < < # < # SIR device drivers < # < CONFIG_IRTTY_SIR=m < < # < # Dongle support < # < CONFIG_DONGLE=y < CONFIG_ESI_DONGLE=m < CONFIG_ACTISYS_DONGLE=m < CONFIG_TEKRAM_DONGLE=m < CONFIG_LITELINK_DONGLE=m < CONFIG_MA600_DONGLE=m < CONFIG_GIRBIL_DONGLE=m < CONFIG_MCP2120_DONGLE=m < CONFIG_OLD_BELKIN_DONGLE=m < CONFIG_ACT200L_DONGLE=m < < # < # Old SIR device drivers < # < < # < # Old Serial dongle support < # < < # < # FIR device drivers < # < CONFIG_USB_IRDA=m < CONFIG_SIGMATEL_FIR=m < CONFIG_NSC_FIR=m < CONFIG_WINBOND_FIR=m < CONFIG_TOSHIBA_FIR=m < CONFIG_SMC_IRCC_FIR=m < CONFIG_ALI_FIR=m < CONFIG_VLSI_FIR=m < CONFIG_VIA_FIR=m --- > # CONFIG_NET_PKTGEN is not set > # CONFIG_HAMRADIO is not set > # CONFIG_IRDA is not set 744c586 < CONFIG_BT_HCIBPA10X=m --- > # CONFIG_BT_HCIBPA10X is not set 746,749d587 < CONFIG_BT_HCIDTL1=m < CONFIG_BT_HCIBT3C=m < CONFIG_BT_HCIBLUECARD=m < CONFIG_BT_HCIBTUART=m 766c604 < CONFIG_FW_LOADER=m --- > CONFIG_FW_LOADER=y 772c610 < CONFIG_CONNECTOR=m --- > # CONFIG_CONNECTOR is not set 785c623 < # CONFIG_MTD_CMDLINE_PARTS is not set --- > CONFIG_MTD_CMDLINE_PARTS=y 796,797c634,635 < CONFIG_INFTL=m < CONFIG_RFD_FTL=m --- > # CONFIG_INFTL is not set > # CONFIG_RFD_FTL is not set 805,809c643 < CONFIG_MTD_CFI_ADV_OPTIONS=y < CONFIG_MTD_CFI_NOSWAP=y < # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set < # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set < # CONFIG_MTD_CFI_GEOMETRY is not set --- > # CONFIG_MTD_CFI_ADV_OPTIONS is not set 820d653 < # CONFIG_MTD_OTP is not set 823c656 < CONFIG_MTD_CFI_AMDSTD_RETRY=0 --- > CONFIG_MTD_CFI_AMDSTD_RETRY=3 835,839c668,669 < CONFIG_MTD_PHYSMAP=m < CONFIG_MTD_PHYSMAP_START=0x8000000 < CONFIG_MTD_PHYSMAP_LEN=0x4000000 < CONFIG_MTD_PHYSMAP_BANKWIDTH=2 < CONFIG_MTD_PNC2000=m --- > # CONFIG_MTD_PHYSMAP is not set > # CONFIG_MTD_PNC2000 is not set 842,845c672,674 < CONFIG_MTD_TS5500=m < CONFIG_MTD_SBC_GXX=m < CONFIG_MTD_SCx200_DOCFLASH=m < CONFIG_MTD_AMD76XROM=m --- > # CONFIG_MTD_TS5500 is not set > # CONFIG_MTD_SBC_GXX is not set > # CONFIG_MTD_AMD76XROM is not set 847,853c676,681 < CONFIG_MTD_SCB2_FLASH=m < CONFIG_MTD_NETtel=m < CONFIG_MTD_DILNETPC=m < CONFIG_MTD_DILNETPC_BOOTSIZE=0x80000 < CONFIG_MTD_L440GX=m < CONFIG_MTD_PCI=m < CONFIG_MTD_PLATRAM=m --- > # CONFIG_MTD_SCB2_FLASH is not set > # CONFIG_MTD_NETtel is not set > # CONFIG_MTD_DILNETPC is not set > # CONFIG_MTD_L440GX is not set > # CONFIG_MTD_PCI is not set > # CONFIG_MTD_PLATRAM is not set 858,864c686,688 < CONFIG_MTD_PMC551=m < # CONFIG_MTD_PMC551_BUGFIX is not set < # CONFIG_MTD_PMC551_DEBUG is not set < CONFIG_MTD_DATAFLASH=m < CONFIG_MTD_M25P80=m < CONFIG_MTD_SLRAM=m < CONFIG_MTD_PHRAM=m --- > # CONFIG_MTD_PMC551 is not set > # CONFIG_MTD_SLRAM is not set > # CONFIG_MTD_PHRAM is not set 868,869c692,693 < CONFIG_MTD_BLKMTD=m < CONFIG_MTD_BLOCK2MTD=m --- > # CONFIG_MTD_BLKMTD is not set > # CONFIG_MTD_BLOCK2MTD is not set 874,880c698,700 < CONFIG_MTD_DOC2000=m < CONFIG_MTD_DOC2001=m < CONFIG_MTD_DOC2001PLUS=m < CONFIG_MTD_DOCPROBE=m < CONFIG_MTD_DOCECC=m < # CONFIG_MTD_DOCPROBE_ADVANCED is not set < CONFIG_MTD_DOCPROBE_ADDRESS=0 --- > # CONFIG_MTD_DOC2000 is not set > # CONFIG_MTD_DOC2001 is not set > # CONFIG_MTD_DOC2001PLUS is not set 888,892c708,709 < CONFIG_MTD_NAND_DISKONCHIP=m < # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set < CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 < CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE=y < CONFIG_MTD_NAND_NANDSIM=m --- > # CONFIG_MTD_NAND_DISKONCHIP is not set > # CONFIG_MTD_NAND_NANDSIM is not set 897,898c714 < CONFIG_MTD_ONENAND=m < # CONFIG_MTD_ONENAND_VERIFY_WRITE is not set --- > # CONFIG_MTD_ONENAND is not set 906,908c722,723 < CONFIG_PARPORT_PC_FIFO=y < CONFIG_PARPORT_PC_SUPERIO=y < CONFIG_PARPORT_PC_PCMCIA=m --- > # CONFIG_PARPORT_PC_FIFO is not set > # CONFIG_PARPORT_PC_SUPERIO is not set 921a737,738 > # CONFIG_ISAPNP is not set > # CONFIG_PNPBIOS is not set 927,958c744,746 < CONFIG_BLK_DEV_FD=y < CONFIG_PARIDE=m < CONFIG_PARIDE_PARPORT=m < < # < # Parallel IDE high-level drivers < # < CONFIG_PARIDE_PD=m < CONFIG_PARIDE_PCD=m < CONFIG_PARIDE_PF=m < CONFIG_PARIDE_PT=m < CONFIG_PARIDE_PG=m < < # < # Parallel IDE protocol modules < # < CONFIG_PARIDE_ATEN=m < CONFIG_PARIDE_BPCK=m < CONFIG_PARIDE_BPCK6=m < CONFIG_PARIDE_COMM=m < CONFIG_PARIDE_DSTR=m < CONFIG_PARIDE_FIT2=m < CONFIG_PARIDE_FIT3=m < CONFIG_PARIDE_EPAT=m < CONFIG_PARIDE_EPATC8=y < CONFIG_PARIDE_EPIA=m < CONFIG_PARIDE_FRIQ=m < CONFIG_PARIDE_FRPW=m < CONFIG_PARIDE_KBIC=m < CONFIG_PARIDE_KTTI=m < CONFIG_PARIDE_ON20=m < CONFIG_PARIDE_ON26=m --- > CONFIG_BLK_DEV_FD=m > # CONFIG_BLK_DEV_XD is not set > # CONFIG_PARIDE is not set 963c751 < CONFIG_BLK_DEV_UMEM=m --- > # CONFIG_BLK_DEV_UMEM is not set 965c753 < CONFIG_BLK_DEV_LOOP=y --- > CONFIG_BLK_DEV_LOOP=m 974,977c762,763 < CONFIG_CDROM_PKTCDVD=m < CONFIG_CDROM_PKTCDVD_BUFFERS=8 < CONFIG_CDROM_PKTCDVD_WCACHE=y < CONFIG_ATA_OVER_ETH=m --- > # CONFIG_CDROM_PKTCDVD is not set > # CONFIG_ATA_OVER_ETH is not set 990c776 < CONFIG_BLK_DEV_IDEDISK=m --- > CONFIG_BLK_DEV_IDEDISK=y 992,995c778,780 < CONFIG_BLK_DEV_IDECS=m < CONFIG_BLK_DEV_IDECD=m < CONFIG_BLK_DEV_IDETAPE=m < CONFIG_BLK_DEV_IDEFLOPPY=m --- > CONFIG_BLK_DEV_IDECD=y > # CONFIG_BLK_DEV_IDETAPE is not set > CONFIG_BLK_DEV_IDEFLOPPY=y 1002,1004c787,788 < CONFIG_IDE_GENERIC=m < CONFIG_BLK_DEV_CMD640=y < CONFIG_BLK_DEV_CMD640_ENHANCED=y --- > CONFIG_IDE_GENERIC=y > # CONFIG_BLK_DEV_CMD640 is not set 1008c792 < CONFIG_BLK_DEV_OFFBOARD=y --- > # CONFIG_BLK_DEV_OFFBOARD is not set 1010,1011c794,795 < CONFIG_BLK_DEV_OPTI621=m < CONFIG_BLK_DEV_RZ1000=m --- > # CONFIG_BLK_DEV_OPTI621 is not set > CONFIG_BLK_DEV_RZ1000=y 1016,1017c800,801 < CONFIG_BLK_DEV_AEC62XX=m < CONFIG_BLK_DEV_ALI15X3=m --- > CONFIG_BLK_DEV_AEC62XX=y > CONFIG_BLK_DEV_ALI15X3=y 1019,1042c803,826 < CONFIG_BLK_DEV_AMD74XX=m < CONFIG_BLK_DEV_ATIIXP=m < CONFIG_BLK_DEV_CMD64X=m < CONFIG_BLK_DEV_TRIFLEX=m < CONFIG_BLK_DEV_CY82C693=m < CONFIG_BLK_DEV_CS5520=m < CONFIG_BLK_DEV_CS5530=m < CONFIG_BLK_DEV_CS5535=m < CONFIG_BLK_DEV_HPT34X=m < CONFIG_HPT34X_AUTODMA=y < CONFIG_BLK_DEV_HPT366=m < CONFIG_BLK_DEV_SC1200=m < CONFIG_BLK_DEV_PIIX=m < CONFIG_BLK_DEV_IT821X=m < CONFIG_BLK_DEV_NS87415=m < CONFIG_BLK_DEV_PDC202XX_OLD=m < CONFIG_PDC202XX_BURST=y < CONFIG_BLK_DEV_PDC202XX_NEW=m < CONFIG_BLK_DEV_SVWKS=m < CONFIG_BLK_DEV_SIIMAGE=m < CONFIG_BLK_DEV_SIS5513=m < CONFIG_BLK_DEV_SLC90E66=m < CONFIG_BLK_DEV_TRM290=m < CONFIG_BLK_DEV_VIA82CXXX=m --- > CONFIG_BLK_DEV_AMD74XX=y > CONFIG_BLK_DEV_ATIIXP=y > CONFIG_BLK_DEV_CMD64X=y > CONFIG_BLK_DEV_TRIFLEX=y > CONFIG_BLK_DEV_CY82C693=y > CONFIG_BLK_DEV_CS5520=y > CONFIG_BLK_DEV_CS5530=y > # CONFIG_BLK_DEV_CS5535 is not set > CONFIG_BLK_DEV_HPT34X=y > # CONFIG_HPT34X_AUTODMA is not set > CONFIG_BLK_DEV_HPT366=y > # CONFIG_BLK_DEV_SC1200 is not set > CONFIG_BLK_DEV_PIIX=y > # CONFIG_BLK_DEV_IT821X is not set > # CONFIG_BLK_DEV_NS87415 is not set > CONFIG_BLK_DEV_PDC202XX_OLD=y > # CONFIG_PDC202XX_BURST is not set > CONFIG_BLK_DEV_PDC202XX_NEW=y > CONFIG_BLK_DEV_SVWKS=y > CONFIG_BLK_DEV_SIIMAGE=y > CONFIG_BLK_DEV_SIS5513=y > CONFIG_BLK_DEV_SLC90E66=y > # CONFIG_BLK_DEV_TRM290 is not set > CONFIG_BLK_DEV_VIA82CXXX=y 1043a828 > # CONFIG_IDE_CHIPSETS is not set 1052c837 < CONFIG_RAID_ATTRS=m --- > # CONFIG_RAID_ATTRS is not set 1063c848 < # CONFIG_BLK_DEV_SR_VENDOR is not set --- > CONFIG_BLK_DEV_SR_VENDOR=y 1065c850 < CONFIG_CHR_DEV_SCH=m --- > # CONFIG_CHR_DEV_SCH is not set 1070c855 < CONFIG_SCSI_MULTI_LUN=y --- > # CONFIG_SCSI_MULTI_LUN is not set 1085c870 < CONFIG_ISCSI_TCP=m --- > # CONFIG_ISCSI_TCP is not set 1087a873 > # CONFIG_SCSI_7000FASST is not set 1088a875,876 > CONFIG_SCSI_AHA152X=m > # CONFIG_SCSI_AHA1542 is not set 1091c879 < CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 --- > CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 1093c881 < CONFIG_AIC7XXX_DEBUG_ENABLE=y --- > # CONFIG_AIC7XXX_DEBUG_ENABLE is not set 1095c883 < CONFIG_AIC7XXX_REG_PRETTY_PRINT=y --- > # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set 1098c886 < CONFIG_AIC79XX_CMDS_PER_DEVICE=32 --- > CONFIG_AIC79XX_CMDS_PER_DEVICE=4 1100,1101c888,889 < CONFIG_AIC79XX_ENABLE_RD_STRM=y < CONFIG_AIC79XX_DEBUG_ENABLE=y --- > # CONFIG_AIC79XX_ENABLE_RD_STRM is not set > # CONFIG_AIC79XX_DEBUG_ENABLE is not set 1103,1104c891,893 < CONFIG_AIC79XX_REG_PRETTY_PRINT=y < CONFIG_SCSI_DPT_I2O=m --- > # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set > # CONFIG_SCSI_DPT_I2O is not set > # CONFIG_SCSI_IN2000 is not set 1108c897 < CONFIG_MEGARAID_LEGACY=m --- > # CONFIG_MEGARAID_LEGACY is not set 1127,1133c916,919 < CONFIG_SCSI_BUSLOGIC=m < # CONFIG_SCSI_OMIT_FLASHPOINT is not set < CONFIG_SCSI_DMX3191D=m < CONFIG_SCSI_EATA=m < CONFIG_SCSI_EATA_TAGGED_QUEUE=y < CONFIG_SCSI_EATA_LINKED_COMMANDS=y < CONFIG_SCSI_EATA_MAX_TAGS=16 --- > # CONFIG_SCSI_BUSLOGIC is not set > # CONFIG_SCSI_DMX3191D is not set > # CONFIG_SCSI_DTC3280 is not set > # CONFIG_SCSI_EATA is not set 1135a922,923 > # CONFIG_SCSI_GENERIC_NCR5380 is not set > # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set 1138c926 < CONFIG_SCSI_INIA100=m --- > # CONFIG_SCSI_INIA100 is not set 1142a931 > # CONFIG_SCSI_NCR53C406A is not set 1148,1152c937,941 < CONFIG_SCSI_IPR=m < CONFIG_SCSI_IPR_TRACE=y < CONFIG_SCSI_IPR_DUMP=y < CONFIG_SCSI_QLOGIC_FC=m < CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y --- > # CONFIG_SCSI_IPR is not set > # CONFIG_SCSI_PAS16 is not set > # CONFIG_SCSI_PSI240I is not set > # CONFIG_SCSI_QLOGIC_FAS is not set > # CONFIG_SCSI_QLOGIC_FC is not set 1154,1155c943 < CONFIG_SCSI_QLA_FC=m < # CONFIG_SCSI_QLA2XXX_EMBEDDED_FIRMWARE is not set --- > # CONFIG_SCSI_QLA_FC is not set 1157,1160c945,952 < CONFIG_SCSI_DC395x=m < CONFIG_SCSI_DC390T=m < CONFIG_SCSI_NSP32=m < CONFIG_SCSI_DEBUG=m --- > # CONFIG_SCSI_SYM53C416 is not set > # CONFIG_SCSI_DC395x is not set > # CONFIG_SCSI_DC390T is not set > # CONFIG_SCSI_T128 is not set > # CONFIG_SCSI_U14_34F is not set > # CONFIG_SCSI_ULTRASTOR is not set > # CONFIG_SCSI_NSP32 is not set > # CONFIG_SCSI_DEBUG is not set 1163,1169c955,957 < # PCMCIA SCSI adapter support < # < CONFIG_PCMCIA_AHA152X=m < CONFIG_PCMCIA_FDOMAIN=m < CONFIG_PCMCIA_NINJA_SCSI=m < CONFIG_PCMCIA_QLOGIC=m < CONFIG_PCMCIA_SYM53C500=m --- > # Old CD-ROM drivers (not SCSI, not IDE) > # > # CONFIG_CD_NO_IDESCSI is not set 1183c971 < CONFIG_MD_FAULTY=m --- > # CONFIG_MD_FAULTY is not set 1199c987 < CONFIG_FUSION_MAX_SGE=128 --- > CONFIG_FUSION_MAX_SGE=40 1206,1231c994 < CONFIG_IEEE1394=m < < # < # Subsystem Options < # < # CONFIG_IEEE1394_VERBOSEDEBUG is not set < # CONFIG_IEEE1394_OUI_DB is not set < CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y < CONFIG_IEEE1394_CONFIG_ROM_IP1394=y < CONFIG_IEEE1394_EXPORT_FULL_API=y < < # < # Device Drivers < # < CONFIG_IEEE1394_PCILYNX=m < CONFIG_IEEE1394_OHCI1394=m < < # < # Protocol Drivers < # < CONFIG_IEEE1394_VIDEO1394=m < CONFIG_IEEE1394_SBP2=m < # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set < CONFIG_IEEE1394_ETH1394=m < CONFIG_IEEE1394_DV1394=m < CONFIG_IEEE1394_RAWIO=m --- > # CONFIG_IEEE1394 is not set 1241c1004 < CONFIG_I2O_BUS=m --- > # CONFIG_I2O_BUS is not set 1252c1015 < CONFIG_EQUALIZER=m --- > # CONFIG_EQUALIZER is not set 1254c1017 < CONFIG_NET_SB1000=m --- > # CONFIG_NET_SB1000 is not set 1259,1267c1022 < CONFIG_ARCNET=m < CONFIG_ARCNET_1201=m < CONFIG_ARCNET_1051=m < CONFIG_ARCNET_RAW=m < CONFIG_ARCNET_CAP=m < CONFIG_ARCNET_COM90xx=m < CONFIG_ARCNET_COM90xxIO=m < CONFIG_ARCNET_RIM_I=m < # CONFIG_ARCNET_COM20020 is not set --- > # CONFIG_ARCNET is not set 1272,1281c1027 < CONFIG_PHYLIB=m < < # < # MII PHY device drivers < # < CONFIG_MARVELL_PHY=m < CONFIG_DAVICOM_PHY=m < CONFIG_QSEMI_PHY=m < CONFIG_LXT_PHY=m < CONFIG_CICADA_PHY=m --- > # CONFIG_PHYLIB is not set 1290c1036 < CONFIG_CASSINI=m --- > # CONFIG_CASSINI is not set 1291a1038,1043 > # CONFIG_EL1 is not set > # CONFIG_EL2 is not set > # CONFIG_ELPLUS is not set > # CONFIG_EL16 is not set > # CONFIG_EL3 is not set > # CONFIG_3C515 is not set 1293a1046,1054 > # CONFIG_LANCE is not set > CONFIG_NET_VENDOR_SMC=y > # CONFIG_WD80x3 is not set > # CONFIG_ULTRA is not set > CONFIG_SMC9194=m > CONFIG_NET_VENDOR_RACAL=y > # CONFIG_NI5010 is not set > # CONFIG_NI52 is not set > # CONFIG_NI65 is not set 1302,1304c1063,1064 < # CONFIG_TULIP_MMIO is not set < CONFIG_TULIP_NAPI=y < CONFIG_TULIP_NAPI_HW_MITIGATION=y --- > CONFIG_TULIP_MMIO=y > # CONFIG_TULIP_NAPI is not set 1308,1309c1068,1070 < CONFIG_ULI526X=m < CONFIG_PCMCIA_XIRCOM=m --- > # CONFIG_ULI526X is not set > # CONFIG_AT1700 is not set > # CONFIG_DEPCA is not set 1310a1072 > # CONFIG_NET_ISA is not set 1314c1076 < # CONFIG_AMD8111E_NAPI is not set --- > CONFIG_AMD8111E_NAPI=y 1316a1079,1080 > # CONFIG_AC3200 is not set > CONFIG_APRICOT=m 1319c1083,1084 < CONFIG_DGRS=m --- > # CONFIG_CS89x0 is not set > # CONFIG_DGRS is not set 1327c1092 < # CONFIG_8139TOO_PIO is not set --- > CONFIG_8139TOO_PIO=y 1333,1334c1098 < CONFIG_SUNDANCE=m < # CONFIG_SUNDANCE_MMIO is not set --- > # CONFIG_SUNDANCE is not set 1337c1101 < # CONFIG_VIA_RHINE_MMIO is not set --- > CONFIG_VIA_RHINE_MMIO=y 1339,1341c1103,1105 < CONFIG_ATP=m < CONFIG_DE600=m < CONFIG_DE620=m --- > # CONFIG_ATP is not set > # CONFIG_DE600 is not set > # CONFIG_DE620 is not set 1353,1354c1117,1118 < CONFIG_HAMACHI=m < CONFIG_YELLOWFIN=m --- > # CONFIG_HAMACHI is not set > # CONFIG_YELLOWFIN is not set 1356,1358c1120,1122 < # CONFIG_R8169_NAPI is not set < CONFIG_R8169_VLAN=y < CONFIG_SIS190=m --- > CONFIG_R8169_NAPI=y > # CONFIG_R8169_VLAN is not set > # CONFIG_SIS190 is not set 1369c1133 < CONFIG_CHELSIO_T1=m --- > # CONFIG_CHELSIO_T1 is not set 1378a1143 > CONFIG_IBMTR=m 1383a1149,1150 > CONFIG_SKISA=m > CONFIG_PROTEON=m 1384a1152 > CONFIG_SMCTR=m 1394,1401c1162,1164 < CONFIG_STRIP=m < CONFIG_PCMCIA_WAVELAN=m < CONFIG_PCMCIA_NETWAVE=m < < # < # Wireless 802.11 Frequency Hopping cards support < # < CONFIG_PCMCIA_RAYCS=m --- > # CONFIG_STRIP is not set > # CONFIG_ARLAN is not set > CONFIG_WAVELAN=m 1415c1178 < CONFIG_NORTEL_HERMES=m --- > # CONFIG_NORTEL_HERMES is not set 1421,1429d1183 < # Wireless 802.11b Pcmcia/Cardbus cards support < # < CONFIG_PCMCIA_HERMES=m < CONFIG_PCMCIA_SPECTRUM=m < CONFIG_AIRO_CS=m < CONFIG_PCMCIA_ATMEL=m < CONFIG_PCMCIA_WL3501=m < < # 1433,1438c1187 < CONFIG_HOSTAP=m < CONFIG_HOSTAP_FIRMWARE=y < CONFIG_HOSTAP_FIRMWARE_NVRAM=y < CONFIG_HOSTAP_PLX=m < CONFIG_HOSTAP_PCI=m < CONFIG_HOSTAP_CS=m --- > # CONFIG_HOSTAP is not set 1442,1455d1190 < # PCMCIA network device support < # < CONFIG_NET_PCMCIA=y < CONFIG_PCMCIA_3C589=m < CONFIG_PCMCIA_3C574=m < CONFIG_PCMCIA_FMVJ18X=m < CONFIG_PCMCIA_PCNET=m < CONFIG_PCMCIA_NMCLAN=m < CONFIG_PCMCIA_SMC91C92=m < CONFIG_PCMCIA_XIRC2PS=m < CONFIG_PCMCIA_AXNET=m < CONFIG_PCMCIA_IBMTR=m < < # 1458,1485c1193 < CONFIG_WAN=y < CONFIG_DSCC4=m < CONFIG_DSCC4_PCISYNC=y < CONFIG_DSCC4_PCI_RST=y < CONFIG_LANMEDIA=m < CONFIG_SYNCLINK_SYNCPPP=m < CONFIG_HDLC=m < CONFIG_HDLC_RAW=y < CONFIG_HDLC_RAW_ETH=y < CONFIG_HDLC_CISCO=y < CONFIG_HDLC_FR=y < CONFIG_HDLC_PPP=y < CONFIG_HDLC_X25=y < CONFIG_PCI200SYN=m < CONFIG_WANXL=m < CONFIG_PC300=m < CONFIG_PC300_MLPPP=y < CONFIG_FARSYNC=m < CONFIG_DLCI=m < CONFIG_DLCI_COUNT=24 < CONFIG_DLCI_MAX=8 < CONFIG_WAN_ROUTER_DRIVERS=y < CONFIG_CYCLADES_SYNC=m < CONFIG_CYCLOMX_X25=y < CONFIG_LAPBETHER=m < CONFIG_X25_ASY=m < CONFIG_SBNI=m < # CONFIG_SBNI_MULTILINE is not set --- > # CONFIG_WAN is not set 1490c1198 < CONFIG_ATM_DUMMY=m --- > # CONFIG_ATM_DUMMY is not set 1497,1498c1205 < CONFIG_ATM_ZATM=m < # CONFIG_ATM_ZATM_DEBUG is not set --- > # CONFIG_ATM_ZATM is not set 1500,1501c1207,1208 < CONFIG_ATM_NICSTAR_USE_SUNI=y < CONFIG_ATM_NICSTAR_USE_IDT77105=y --- > # CONFIG_ATM_NICSTAR_USE_SUNI is not set > # CONFIG_ATM_NICSTAR_USE_IDT77105 is not set 1504c1211 < CONFIG_ATM_IDT77252_RCV_ALL=y --- > # CONFIG_ATM_IDT77252_RCV_ALL is not set 1510,1511c1217 < CONFIG_ATM_IA=m < # CONFIG_ATM_IA_DEBUG is not set --- > # CONFIG_ATM_IA is not set 1513,1518c1219 < CONFIG_ATM_FORE200E_PCA=y < CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y < CONFIG_ATM_FORE200E_USE_TASKLET=y < CONFIG_ATM_FORE200E_TX_RETRY=16 < CONFIG_ATM_FORE200E_DEBUG=0 < CONFIG_ATM_FORE200E=m --- > # CONFIG_ATM_FORE200E_PCA is not set 1520c1221 < CONFIG_ATM_HE_USE_SUNI=y --- > # CONFIG_ATM_HE_USE_SUNI is not set 1523,1527c1224,1226 < CONFIG_SKFP=m < CONFIG_HIPPI=y < CONFIG_ROADRUNNER=m < CONFIG_ROADRUNNER_LARGE_RINGS=y < CONFIG_PLIP=m --- > # CONFIG_SKFP is not set > # CONFIG_HIPPI is not set > # CONFIG_PLIP is not set 1534,1535c1233,1234 < CONFIG_PPP_BSDCOMP=m < CONFIG_PPP_MPPE=m --- > # CONFIG_PPP_BSDCOMP is not set > # CONFIG_PPP_MPPE is not set 1538,1541c1237 < CONFIG_SLIP=m < CONFIG_SLIP_COMPRESSED=y < CONFIG_SLIP_SMART=y < CONFIG_SLIP_MODE_SLIP6=y --- > # CONFIG_SLIP is not set 1543c1239 < CONFIG_SHAPER=m --- > # CONFIG_SHAPER is not set 1546c1242 < CONFIG_NETPOLL_RX=y --- > # CONFIG_NETPOLL_RX is not set 1563c1259 < CONFIG_ISDN_PPP_BSDCOMP=m --- > # CONFIG_ISDN_PPP_BSDCOMP is not set 1566d1261 < CONFIG_ISDN_X25=y 1571c1266,1267 < CONFIG_ISDN_DIVERSION=m --- > CONFIG_ISDN_DRV_LOOP=m > # CONFIG_ISDN_DIVERSION is not set 1587,1589c1283,1285 < # CONFIG_HISAX_NO_SENDCOMPLETE is not set < # CONFIG_HISAX_NO_LLC is not set < # CONFIG_HISAX_NO_KEYPAD is not set --- > CONFIG_HISAX_NO_SENDCOMPLETE=y > CONFIG_HISAX_NO_LLC=y > CONFIG_HISAX_NO_KEYPAD=y 1596a1293 > CONFIG_HISAX_16_0=y 1599a1297 > CONFIG_HISAX_AVM_A1=y 1602a1301 > CONFIG_HISAX_IX1MICROR2=y 1603a1303,1305 > CONFIG_HISAX_ASUSCOM=y > CONFIG_HISAX_TELEINT=y > CONFIG_HISAX_HFCS=y 1604a1307,1308 > CONFIG_HISAX_SPORTSTER=y > CONFIG_HISAX_MIC=y 1607a1312,1313 > CONFIG_HISAX_ISURF=y > CONFIG_HISAX_HSTSAPHIR=y 1620,1623d1325 < CONFIG_HISAX_SEDLBAUER_CS=m < CONFIG_HISAX_ELSA_CS=m < CONFIG_HISAX_AVM_A1_CS=m < CONFIG_HISAX_TELES_CS=m 1630c1332 < CONFIG_HISAX_HFC4S8S=m --- > # CONFIG_HISAX_HFC4S8S is not set 1636a1339,1344 > CONFIG_ISDN_DRV_ICN=m > CONFIG_ISDN_DRV_PCBIT=m > CONFIG_ISDN_DRV_SC=m > CONFIG_ISDN_DRV_ACT2000=m > CONFIG_HYSDN=m > CONFIG_HYSDN_CAPI=y 1656a1365 > CONFIG_ISDN_DRV_AVMB1_B1ISA=m 1658a1368 > CONFIG_ISDN_DRV_AVMB1_T1ISA=m 1660d1369 < CONFIG_ISDN_DRV_AVMB1_AVM_CS=m 1678,1680c1387 < CONFIG_PHONE=m < CONFIG_PHONE_IXJ=m < CONFIG_PHONE_IXJ_PCMCIA=m --- > # CONFIG_PHONE is not set 1691c1398 < CONFIG_INPUT_MOUSEDEV_PSAUX=y --- > # CONFIG_INPUT_MOUSEDEV_PSAUX is not set 1695,1699c1402,1404 < CONFIG_INPUT_TSDEV=m < CONFIG_INPUT_TSDEV_SCREEN_X=240 < CONFIG_INPUT_TSDEV_SCREEN_Y=320 < CONFIG_INPUT_EVDEV=m < CONFIG_INPUT_EVBUG=m --- > # CONFIG_INPUT_TSDEV is not set > CONFIG_INPUT_EVDEV=y > # CONFIG_INPUT_EVBUG is not set 1706,1709c1411,1414 < CONFIG_KEYBOARD_SUNKBD=m < CONFIG_KEYBOARD_LKKBD=m < CONFIG_KEYBOARD_XTKBD=m < CONFIG_KEYBOARD_NEWTON=m --- > # CONFIG_KEYBOARD_SUNKBD is not set > # CONFIG_KEYBOARD_LKKBD is not set > # CONFIG_KEYBOARD_XTKBD is not set > # CONFIG_KEYBOARD_NEWTON is not set 1712a1418,1421 > CONFIG_MOUSE_INPORT=m > CONFIG_MOUSE_ATIXL=y > CONFIG_MOUSE_LOGIBM=m > CONFIG_MOUSE_PC110PAD=m 1715,1738c1424,1445 < CONFIG_JOYSTICK_ANALOG=m < CONFIG_JOYSTICK_A3D=m < CONFIG_JOYSTICK_ADI=m < CONFIG_JOYSTICK_COBRA=m < CONFIG_JOYSTICK_GF2K=m < CONFIG_JOYSTICK_GRIP=m < CONFIG_JOYSTICK_GRIP_MP=m < CONFIG_JOYSTICK_GUILLEMOT=m < CONFIG_JOYSTICK_INTERACT=m < CONFIG_JOYSTICK_SIDEWINDER=m < CONFIG_JOYSTICK_TMDC=m < CONFIG_JOYSTICK_IFORCE=m < CONFIG_JOYSTICK_IFORCE_USB=y < CONFIG_JOYSTICK_IFORCE_232=y < CONFIG_JOYSTICK_WARRIOR=m < CONFIG_JOYSTICK_MAGELLAN=m < CONFIG_JOYSTICK_SPACEORB=m < CONFIG_JOYSTICK_SPACEBALL=m < CONFIG_JOYSTICK_STINGER=m < CONFIG_JOYSTICK_TWIDJOY=m < CONFIG_JOYSTICK_DB9=m < CONFIG_JOYSTICK_GAMECON=m < CONFIG_JOYSTICK_TURBOGRAFX=m < CONFIG_JOYSTICK_JOYDUMP=m --- > # CONFIG_JOYSTICK_ANALOG is not set > # CONFIG_JOYSTICK_A3D is not set > # CONFIG_JOYSTICK_ADI is not set > # CONFIG_JOYSTICK_COBRA is not set > # CONFIG_JOYSTICK_GF2K is not set > # CONFIG_JOYSTICK_GRIP is not set > # CONFIG_JOYSTICK_GRIP_MP is not set > # CONFIG_JOYSTICK_GUILLEMOT is not set > # CONFIG_JOYSTICK_INTERACT is not set > # CONFIG_JOYSTICK_SIDEWINDER is not set > # CONFIG_JOYSTICK_TMDC is not set > # CONFIG_JOYSTICK_IFORCE is not set > # CONFIG_JOYSTICK_WARRIOR is not set > # CONFIG_JOYSTICK_MAGELLAN is not set > # CONFIG_JOYSTICK_SPACEORB is not set > # CONFIG_JOYSTICK_SPACEBALL is not set > # CONFIG_JOYSTICK_STINGER is not set > # CONFIG_JOYSTICK_TWIDJOY is not set > # CONFIG_JOYSTICK_DB9 is not set > # CONFIG_JOYSTICK_GAMECON is not set > # CONFIG_JOYSTICK_TURBOGRAFX is not set > # CONFIG_JOYSTICK_JOYDUMP is not set 1740d1446 < CONFIG_TOUCHSCREEN_ADS7846=m 1742,1744c1448,1450 < CONFIG_TOUCHSCREEN_ELO=m < CONFIG_TOUCHSCREEN_MTOUCH=m < CONFIG_TOUCHSCREEN_MK712=m --- > # CONFIG_TOUCHSCREEN_ELO is not set > # CONFIG_TOUCHSCREEN_MTOUCH is not set > # CONFIG_TOUCHSCREEN_MK712 is not set 1747c1453 < CONFIG_INPUT_WISTRON_BTNS=m --- > # CONFIG_INPUT_WISTRON_BTNS is not set 1755,1758c1461,1464 < CONFIG_SERIO_SERPORT=m < CONFIG_SERIO_CT82C710=m < CONFIG_SERIO_PARKBD=m < CONFIG_SERIO_PCIPS2=m --- > CONFIG_SERIO_SERPORT=y > # CONFIG_SERIO_CT82C710 is not set > # CONFIG_SERIO_PARKBD is not set > # CONFIG_SERIO_PCIPS2 is not set 1760,1765c1466,1467 < CONFIG_SERIO_RAW=m < CONFIG_GAMEPORT=m < CONFIG_GAMEPORT_NS558=m < CONFIG_GAMEPORT_L4=m < CONFIG_GAMEPORT_EMU10K1=m < CONFIG_GAMEPORT_FM801=m --- > # CONFIG_SERIO_RAW is not set > # CONFIG_GAMEPORT is not set 1773c1475,1494 < # CONFIG_SERIAL_NONSTANDARD is not set --- > CONFIG_SERIAL_NONSTANDARD=y > # CONFIG_COMPUTONE is not set > # CONFIG_ROCKETPORT is not set > # CONFIG_CYCLADES is not set > # CONFIG_DIGIEPCA is not set > # CONFIG_ESPSERIAL is not set > # CONFIG_MOXA_INTELLIO is not set > # CONFIG_MOXA_SMARTIO is not set > # CONFIG_ISI is not set > CONFIG_SYNCLINK=m > CONFIG_SYNCLINKMP=m > # CONFIG_SYNCLINK_GT is not set > CONFIG_N_HDLC=m > # CONFIG_RISCOM8 is not set > # CONFIG_SPECIALIX is not set > # CONFIG_SX is not set > # CONFIG_RIO is not set > CONFIG_STALDRV=y > # CONFIG_STALLION is not set > # CONFIG_ISTALLION is not set 1778,1779c1499,1500 < CONFIG_SERIAL_8250=m < # CONFIG_SERIAL_8250_CS is not set --- > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y 1783c1504,1508 < # CONFIG_SERIAL_8250_EXTENDED is not set --- > CONFIG_SERIAL_8250_EXTENDED=y > # CONFIG_SERIAL_8250_MANY_PORTS is not set > CONFIG_SERIAL_8250_SHARE_IRQ=y > CONFIG_SERIAL_8250_DETECT_IRQ=y > CONFIG_SERIAL_8250_RSA=y 1788,1789c1513,1515 < CONFIG_SERIAL_CORE=m < CONFIG_SERIAL_JSM=m --- > CONFIG_SERIAL_CORE=y > CONFIG_SERIAL_CORE_CONSOLE=y > # CONFIG_SERIAL_JSM is not set 1791,1792c1517 < CONFIG_LEGACY_PTYS=y < CONFIG_LEGACY_PTY_COUNT=256 --- > # CONFIG_LEGACY_PTYS is not set 1794c1519 < # CONFIG_LP_CONSOLE is not set --- > CONFIG_LP_CONSOLE=y 1796c1521 < CONFIG_TIPAR=m --- > # CONFIG_TIPAR is not set 1825c1550 < CONFIG_IBMASR=m --- > # CONFIG_IBMASR is not set 1827c1552 < CONFIG_I6300ESB_WDT=m --- > # CONFIG_I6300ESB_WDT is not set 1830,1832c1555,1556 < CONFIG_SCx200_WDT=m < CONFIG_60XX_WDT=m < CONFIG_SBC8360_WDT=m --- > # CONFIG_60XX_WDT is not set > # CONFIG_SBC8360_WDT is not set 1836c1560 < CONFIG_W83977F_WDT=m --- > # CONFIG_W83977F_WDT is not set 1838c1562,1570 < CONFIG_SBC_EPX_C3_WATCHDOG=m --- > # CONFIG_SBC_EPX_C3_WATCHDOG is not set > > # > # ISA-based Watchdog Cards > # > CONFIG_PCWATCHDOG=m > # CONFIG_MIXCOMWD is not set > CONFIG_WDT=m > # CONFIG_WDT_501 is not set 1853,1855c1585 < CONFIG_RTC=m < CONFIG_GEN_RTC=m < CONFIG_GEN_RTC_X=y --- > CONFIG_RTC=y 1857,1858c1587,1588 < CONFIG_R3964=m < CONFIG_APPLICOM=m --- > # CONFIG_R3964 is not set > # CONFIG_APPLICOM is not set 1864,1876c1594,1607 < CONFIG_AGP=m < CONFIG_AGP_ALI=m < CONFIG_AGP_ATI=m < CONFIG_AGP_AMD=m < CONFIG_AGP_AMD64=m < CONFIG_AGP_INTEL=m < CONFIG_AGP_NVIDIA=m < CONFIG_AGP_SIS=m < CONFIG_AGP_SWORKS=m < CONFIG_AGP_VIA=m < CONFIG_AGP_EFFICEON=m < CONFIG_DRM=m < CONFIG_DRM_TDFX=m --- > # CONFIG_FTAPE is not set > CONFIG_AGP=y > CONFIG_AGP_ALI=y > CONFIG_AGP_ATI=y > CONFIG_AGP_AMD=y > CONFIG_AGP_AMD64=y > CONFIG_AGP_INTEL=y > CONFIG_AGP_NVIDIA=y > CONFIG_AGP_SIS=y > CONFIG_AGP_SWORKS=y > CONFIG_AGP_VIA=y > CONFIG_AGP_EFFICEON=y > CONFIG_DRM=y > # CONFIG_DRM_TDFX is not set 1883,1897c1614,1620 < CONFIG_DRM_SIS=m < CONFIG_DRM_VIA=m < CONFIG_DRM_SAVAGE=m < < # < # PCMCIA character devices < # < CONFIG_SYNCLINK_CS=m < CONFIG_CARDMAN_4000=m < CONFIG_CARDMAN_4040=m < CONFIG_MWAVE=m < CONFIG_SCx200_GPIO=m < CONFIG_CS5535_GPIO=m < CONFIG_RAW_DRIVER=m < CONFIG_MAX_RAW_DEVS=256 --- > # CONFIG_DRM_SIS is not set > # CONFIG_DRM_VIA is not set > # CONFIG_DRM_SAVAGE is not set > # CONFIG_MWAVE is not set > # CONFIG_CS5535_GPIO is not set > CONFIG_RAW_DRIVER=y > CONFIG_MAX_RAW_DEVS=8192 1904,1910c1627,1628 < CONFIG_TCG_TPM=m < CONFIG_TCG_TIS=m < CONFIG_TCG_NSC=m < CONFIG_TCG_ATMEL=m < CONFIG_TCG_INFINEON=m < CONFIG_TCG_XEN=m < CONFIG_TELCLOCK=m --- > # CONFIG_TCG_TPM is not set > # CONFIG_TELCLOCK is not set 1932c1650 < CONFIG_I2C_AMD756_S4882=m --- > # CONFIG_I2C_AMD756_S4882 is not set 1933a1652 > # CONFIG_I2C_ELEKTOR is not set 1939,1940c1658,1659 < CONFIG_I2C_PARPORT=m < CONFIG_I2C_PARPORT_LIGHT=m --- > # CONFIG_I2C_PARPORT is not set > # CONFIG_I2C_PARPORT_LIGHT is not set 1943,1946c1662 < CONFIG_SCx200_I2C=m < CONFIG_SCx200_I2C_SCL=12 < CONFIG_SCx200_I2C_SDA=13 < CONFIG_SCx200_ACB=m --- > # CONFIG_SCx200_ACB is not set 1950c1666 < CONFIG_I2C_STUB=m --- > # CONFIG_I2C_STUB is not set 1954c1670 < CONFIG_I2C_PCA_ISA=m --- > # CONFIG_I2C_PCA_ISA is not set 1959,1960c1675,1676 < CONFIG_SENSORS_DS1337=m < CONFIG_SENSORS_DS1374=m --- > # CONFIG_SENSORS_DS1337 is not set > # CONFIG_SENSORS_DS1374 is not set 1963c1679 < CONFIG_SENSORS_PCA9539=m --- > # CONFIG_SENSORS_PCA9539 is not set 1966,1967c1682,1683 < CONFIG_SENSORS_MAX6875=m < CONFIG_RTC_X1205_I2C=m --- > # CONFIG_SENSORS_MAX6875 is not set > # CONFIG_RTC_X1205_I2C is not set 1976,1988c1692,1693 < CONFIG_SPI=y < # CONFIG_SPI_DEBUG is not set < CONFIG_SPI_MASTER=y < < # < # SPI Master Controller Drivers < # < CONFIG_SPI_BITBANG=m < CONFIG_SPI_BUTTERFLY=m < < # < # SPI Protocol Masters < # --- > # CONFIG_SPI is not set > # CONFIG_SPI_MASTER is not set 1993,2000c1698 < CONFIG_W1=m < CONFIG_W1_MATROX=m < CONFIG_W1_DS9490=m < CONFIG_W1_DS9490_BRIDGE=m < CONFIG_W1_THERM=m < CONFIG_W1_SMEM=m < CONFIG_W1_DS2433=m < CONFIG_W1_DS2433_CRC=y --- > # CONFIG_W1 is not set 2011c1709 < CONFIG_SENSORS_ADM9240=m --- > # CONFIG_SENSORS_ADM9240 is not set 2013c1711 < CONFIG_SENSORS_ATXP1=m --- > # CONFIG_SENSORS_ATXP1 is not set 2015c1713 < CONFIG_SENSORS_F71805F=m --- > # CONFIG_SENSORS_F71805F is not set 2017c1715 < CONFIG_SENSORS_FSCPOS=m --- > # CONFIG_SENSORS_FSCPOS is not set 2019c1717 < CONFIG_SENSORS_GL520SM=m --- > # CONFIG_SENSORS_GL520SM is not set 2021c1719 < CONFIG_SENSORS_LM63=m --- > # CONFIG_SENSORS_LM63 is not set 2030c1728 < CONFIG_SENSORS_LM92=m --- > # CONFIG_SENSORS_LM92 is not set 2032,2033c1730,1731 < CONFIG_SENSORS_PC87360=m < CONFIG_SENSORS_SIS5595=m --- > # CONFIG_SENSORS_PC87360 is not set > # CONFIG_SENSORS_SIS5595 is not set 2035c1733 < CONFIG_SENSORS_SMSC47B397=m --- > # CONFIG_SENSORS_SMSC47B397 is not set 2037c1735 < CONFIG_SENSORS_VT8231=m --- > # CONFIG_SENSORS_VT8231 is not set 2039c1737 < CONFIG_SENSORS_W83792D=m --- > # CONFIG_SENSORS_W83792D is not set 2042,2043c1740,1741 < CONFIG_SENSORS_W83627EHF=m < CONFIG_SENSORS_HDAPS=m --- > # CONFIG_SENSORS_W83627EHF is not set > # CONFIG_SENSORS_HDAPS is not set 2068,2102c1766,1784 < CONFIG_VIDEO_BT848=m < CONFIG_VIDEO_BT848_DVB=y < CONFIG_VIDEO_SAA6588=m < CONFIG_VIDEO_BWQCAM=m < CONFIG_VIDEO_CQCAM=m < CONFIG_VIDEO_W9966=m < CONFIG_VIDEO_CPIA=m < CONFIG_VIDEO_CPIA_PP=m < CONFIG_VIDEO_CPIA_USB=m < CONFIG_VIDEO_SAA5246A=m < CONFIG_VIDEO_SAA5249=m < CONFIG_TUNER_3036=m < CONFIG_VIDEO_STRADIS=m < CONFIG_VIDEO_ZORAN=m < CONFIG_VIDEO_ZORAN_BUZ=m < CONFIG_VIDEO_ZORAN_DC10=m < CONFIG_VIDEO_ZORAN_DC30=m < CONFIG_VIDEO_ZORAN_LML33=m < CONFIG_VIDEO_ZORAN_LML33R10=m < CONFIG_VIDEO_MEYE=m < CONFIG_VIDEO_SAA7134=m < CONFIG_VIDEO_SAA7134_ALSA=m < # CONFIG_VIDEO_SAA7134_OSS is not set < CONFIG_VIDEO_SAA7134_DVB=m < CONFIG_VIDEO_SAA7134_DVB_ALL_FRONTENDS=y < CONFIG_VIDEO_MXB=m < CONFIG_VIDEO_DPC=m < CONFIG_VIDEO_HEXIUM_ORION=m < CONFIG_VIDEO_HEXIUM_GEMINI=m < CONFIG_VIDEO_CX88=m < CONFIG_VIDEO_CX88_ALSA=m < CONFIG_VIDEO_CX88_DVB=m < CONFIG_VIDEO_CX88_DVB_ALL_FRONTENDS=y < CONFIG_VIDEO_CX88_VP3054=m < CONFIG_VIDEO_EM28XX=m --- > # CONFIG_VIDEO_BT848 is not set > # CONFIG_VIDEO_PMS is not set > # CONFIG_VIDEO_BWQCAM is not set > # CONFIG_VIDEO_CQCAM is not set > # CONFIG_VIDEO_W9966 is not set > # CONFIG_VIDEO_CPIA is not set > # CONFIG_VIDEO_SAA5246A is not set > # CONFIG_VIDEO_SAA5249 is not set > # CONFIG_TUNER_3036 is not set > # CONFIG_VIDEO_STRADIS is not set > # CONFIG_VIDEO_ZORAN is not set > # CONFIG_VIDEO_MEYE is not set > # CONFIG_VIDEO_SAA7134 is not set > # CONFIG_VIDEO_MXB is not set > # CONFIG_VIDEO_DPC is not set > # CONFIG_VIDEO_HEXIUM_ORION is not set > # CONFIG_VIDEO_HEXIUM_GEMINI is not set > # CONFIG_VIDEO_CX88 is not set > # CONFIG_VIDEO_EM28XX is not set 2104,2105c1786,1787 < CONFIG_VIDEO_AUDIO_DECODER=m < CONFIG_VIDEO_DECODER=m --- > # CONFIG_VIDEO_AUDIO_DECODER is not set > # CONFIG_VIDEO_DECODER is not set 2110,2112c1792,1805 < CONFIG_RADIO_GEMTEK_PCI=m < CONFIG_RADIO_MAXIRADIO=m < CONFIG_RADIO_MAESTRO=m --- > # CONFIG_RADIO_CADET is not set > # CONFIG_RADIO_RTRACK is not set > # CONFIG_RADIO_RTRACK2 is not set > # CONFIG_RADIO_AZTECH is not set > # CONFIG_RADIO_GEMTEK is not set > # CONFIG_RADIO_GEMTEK_PCI is not set > # CONFIG_RADIO_MAXIRADIO is not set > # CONFIG_RADIO_MAESTRO is not set > # CONFIG_RADIO_SF16FMI is not set > # CONFIG_RADIO_SF16FMR2 is not set > # CONFIG_RADIO_TERRATEC is not set > # CONFIG_RADIO_TRUST is not set > # CONFIG_RADIO_TYPHOON is not set > # CONFIG_RADIO_ZOLTRIX is not set 2117,2225c1810 < CONFIG_DVB=y < CONFIG_DVB_CORE=m < < # < # Supported SAA7146 based PCI Adapters < # < CONFIG_DVB_AV7110=m < CONFIG_DVB_AV7110_OSD=y < CONFIG_DVB_BUDGET=m < CONFIG_DVB_BUDGET_CI=m < CONFIG_DVB_BUDGET_AV=m < CONFIG_DVB_BUDGET_PATCH=m < < # < # Supported USB Adapters < # < CONFIG_DVB_USB=m < # CONFIG_DVB_USB_DEBUG is not set < CONFIG_DVB_USB_A800=m < CONFIG_DVB_USB_DIBUSB_MB=m < # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set < CONFIG_DVB_USB_DIBUSB_MC=m < CONFIG_DVB_USB_UMT_010=m < CONFIG_DVB_USB_CXUSB=m < CONFIG_DVB_USB_DIGITV=m < CONFIG_DVB_USB_VP7045=m < CONFIG_DVB_USB_VP702X=m < CONFIG_DVB_USB_NOVA_T_USB2=m < CONFIG_DVB_USB_DTT200U=m < CONFIG_DVB_TTUSB_BUDGET=m < CONFIG_DVB_TTUSB_DEC=m < CONFIG_DVB_CINERGYT2=m < # CONFIG_DVB_CINERGYT2_TUNING is not set < < # < # Supported FlexCopII (B2C2) Adapters < # < CONFIG_DVB_B2C2_FLEXCOP=m < CONFIG_DVB_B2C2_FLEXCOP_PCI=m < CONFIG_DVB_B2C2_FLEXCOP_USB=m < # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set < < # < # Supported BT878 Adapters < # < CONFIG_DVB_BT8XX=m < < # < # Supported Pluto2 Adapters < # < CONFIG_DVB_PLUTO2=m < < # < # Supported DVB Frontends < # < < # < # Customise DVB Frontends < # < < # < # DVB-S (satellite) frontends < # < CONFIG_DVB_STV0299=m < CONFIG_DVB_CX24110=m < CONFIG_DVB_CX24123=m < CONFIG_DVB_TDA8083=m < CONFIG_DVB_MT312=m < CONFIG_DVB_VES1X93=m < CONFIG_DVB_S5H1420=m < < # < # DVB-T (terrestrial) frontends < # < CONFIG_DVB_SP8870=m < CONFIG_DVB_SP887X=m < CONFIG_DVB_CX22700=m < CONFIG_DVB_CX22702=m < CONFIG_DVB_L64781=m < CONFIG_DVB_TDA1004X=m < CONFIG_DVB_NXT6000=m < CONFIG_DVB_MT352=m < CONFIG_DVB_DIB3000MB=m < CONFIG_DVB_DIB3000MC=m < < # < # DVB-C (cable) frontends < # < CONFIG_DVB_VES1820=m < CONFIG_DVB_TDA10021=m < CONFIG_DVB_STV0297=m < < # < # ATSC (North American/Korean Terresterial DTV) frontends < # < CONFIG_DVB_NXT200X=m < CONFIG_DVB_OR51211=m < CONFIG_DVB_OR51132=m < CONFIG_DVB_BCM3510=m < CONFIG_DVB_LGDT330X=m < CONFIG_VIDEO_SAA7146=m < CONFIG_VIDEO_SAA7146_VV=m < CONFIG_VIDEO_VIDEOBUF=m < CONFIG_VIDEO_TUNER=m < CONFIG_VIDEO_BUF=m < CONFIG_VIDEO_BUF_DVB=m < CONFIG_VIDEO_BTCX=m < CONFIG_VIDEO_IR=m < CONFIG_VIDEO_TVEEPROM=m --- > # CONFIG_DVB is not set 2236c1821 < CONFIG_FB_TILEBLITTING=y --- > # CONFIG_FB_TILEBLITTING is not set 2238,2241c1823,1825 < CONFIG_FB_PM2=m < CONFIG_FB_PM2_FIFO_DISCONNECT=y < CONFIG_FB_CYBER2000=m < CONFIG_FB_ARC=m --- > # CONFIG_FB_PM2 is not set > # CONFIG_FB_CYBER2000 is not set > # CONFIG_FB_ARC is not set 2247,2251c1831,1833 < CONFIG_FB_HGA=m < # CONFIG_FB_HGA_ACCEL is not set < CONFIG_FB_S1D13XXX=m < CONFIG_FB_NVIDIA=m < CONFIG_FB_NVIDIA_I2C=y --- > # CONFIG_FB_HGA is not set > # CONFIG_FB_S1D13XXX is not set > # CONFIG_FB_NVIDIA is not set 2253,2254c1835,1836 < CONFIG_FB_RIVA_I2C=y < CONFIG_FB_RIVA_DEBUG=y --- > # CONFIG_FB_RIVA_I2C is not set > # CONFIG_FB_RIVA_DEBUG is not set 2256,2264c1838,1841 < # CONFIG_FB_I810_GTF is not set < CONFIG_FB_INTEL=m < # CONFIG_FB_INTEL_DEBUG is not set < CONFIG_FB_MATROX=m < CONFIG_FB_MATROX_MILLENIUM=y < CONFIG_FB_MATROX_MYSTIQUE=y < CONFIG_FB_MATROX_G=y < # CONFIG_FB_MATROX_I2C is not set < CONFIG_FB_MATROX_MULTIHEAD=y --- > CONFIG_FB_I810_GTF=y > # CONFIG_FB_I810_I2C is not set > # CONFIG_FB_INTEL is not set > # CONFIG_FB_MATROX is not set 2266,2280c1843,1848 < CONFIG_FB_RADEON=m < CONFIG_FB_RADEON_I2C=y < # CONFIG_FB_RADEON_DEBUG is not set < CONFIG_FB_ATY128=m < CONFIG_FB_ATY=m < CONFIG_FB_ATY_CT=y < CONFIG_FB_ATY_GENERIC_LCD=y < CONFIG_FB_ATY_GX=y < CONFIG_FB_SAVAGE=m < CONFIG_FB_SAVAGE_I2C=y < CONFIG_FB_SAVAGE_ACCEL=y < CONFIG_FB_SIS=m < CONFIG_FB_SIS_300=y < CONFIG_FB_SIS_315=y < CONFIG_FB_NEOMAGIC=m --- > # CONFIG_FB_RADEON is not set > # CONFIG_FB_ATY128 is not set > # CONFIG_FB_ATY is not set > # CONFIG_FB_SAVAGE is not set > # CONFIG_FB_SIS is not set > # CONFIG_FB_NEOMAGIC is not set 2282,2290c1850,1855 < CONFIG_FB_3DFX=m < # CONFIG_FB_3DFX_ACCEL is not set < CONFIG_FB_VOODOO1=m < CONFIG_FB_CYBLA=m < CONFIG_FB_TRIDENT=m < # CONFIG_FB_TRIDENT_ACCEL is not set < CONFIG_FB_GEODE=y < CONFIG_FB_GEODE_GX1=m < CONFIG_FB_VIRTUAL=m --- > # CONFIG_FB_3DFX is not set > # CONFIG_FB_VOODOO1 is not set > # CONFIG_FB_CYBLA is not set > # CONFIG_FB_TRIDENT is not set > # CONFIG_FB_GEODE is not set > # CONFIG_FB_VIRTUAL is not set 2295a1861 > CONFIG_MDA_CONSOLE=m 2297c1863 < CONFIG_FRAMEBUFFER_CONSOLE=m --- > CONFIG_FRAMEBUFFER_CONSOLE=y 2306,2311c1872,1876 < # CONFIG_LOGO is not set < CONFIG_BACKLIGHT_LCD_SUPPORT=y < CONFIG_BACKLIGHT_CLASS_DEVICE=m < CONFIG_BACKLIGHT_DEVICE=y < CONFIG_LCD_CLASS_DEVICE=m < CONFIG_LCD_DEVICE=y --- > CONFIG_LOGO=y > # CONFIG_LOGO_LINUX_MONO is not set > # CONFIG_LOGO_LINUX_VGA16 is not set > CONFIG_LOGO_LINUX_CLUT224=y > # CONFIG_BACKLIGHT_LCD_SUPPORT is not set 2350c1915 < CONFIG_SND_SERIAL_U16550=m --- > # CONFIG_SND_SERIAL_U16550 is not set 2353a1919,1949 > # ISA devices > # > # CONFIG_SND_AD1816A is not set > # CONFIG_SND_AD1848 is not set > # CONFIG_SND_ALS100 is not set > # CONFIG_SND_AZT2320 is not set > # CONFIG_SND_CMI8330 is not set > # CONFIG_SND_CS4231 is not set > # CONFIG_SND_CS4232 is not set > # CONFIG_SND_CS4236 is not set > # CONFIG_SND_DT019X is not set > # CONFIG_SND_ES968 is not set > # CONFIG_SND_ES1688 is not set > # CONFIG_SND_ES18XX is not set > # CONFIG_SND_GUSCLASSIC is not set > # CONFIG_SND_GUSEXTREME is not set > # CONFIG_SND_GUSMAX is not set > # CONFIG_SND_INTERWAVE is not set > # CONFIG_SND_INTERWAVE_STB is not set > # CONFIG_SND_OPL3SA2 is not set > # CONFIG_SND_OPTI92X_AD1848 is not set > # CONFIG_SND_OPTI92X_CS4231 is not set > # CONFIG_SND_OPTI93X is not set > # CONFIG_SND_SB8 is not set > # CONFIG_SND_SB16 is not set > # CONFIG_SND_SBAWE is not set > # CONFIG_SND_SGALAXY is not set > # CONFIG_SND_SSCAPE is not set > # CONFIG_SND_WAVEFRONT is not set > > # 2356c1952 < CONFIG_SND_AD1889=m --- > # CONFIG_SND_AD1889 is not set 2367c1963 < CONFIG_SND_CA0106=m --- > # CONFIG_SND_CA0106 is not set 2372c1968 < CONFIG_SND_CS5535AUDIO=m --- > # CONFIG_SND_CS5535AUDIO is not set 2374c1970 < CONFIG_SND_EMU10K1X=m --- > # CONFIG_SND_EMU10K1X is not set 2381c1977 < CONFIG_SND_HDA_INTEL=m --- > # CONFIG_SND_HDA_INTEL is not set 2383c1979 < CONFIG_SND_HDSPM=m --- > # CONFIG_SND_HDSPM is not set 2392c1988 < CONFIG_SND_PCXHR=m --- > # CONFIG_SND_PCXHR is not set 2410,2413d2005 < # PCMCIA devices < # < < # 2416,2424c2008 < CONFIG_SOUND_PRIME=m < # CONFIG_OBSOLETE_OSS_DRIVER is not set < CONFIG_SOUND_FUSION=m < CONFIG_SOUND_ICH=m < CONFIG_SOUND_TRIDENT=m < # CONFIG_SOUND_MSNDCLAS is not set < # CONFIG_SOUND_MSNDPIN is not set < # CONFIG_SOUND_OSS is not set < CONFIG_SOUND_TVMIXER=m --- > # CONFIG_SOUND_PRIME is not set 2431c2015 < CONFIG_USB=m --- > CONFIG_USB=y 2438c2022 < CONFIG_USB_BANDWIDTH=y --- > # CONFIG_USB_BANDWIDTH is not set 2440c2024 < # CONFIG_USB_SUSPEND is not set --- > CONFIG_USB_SUSPEND=y 2449c2033 < CONFIG_USB_ISP116X_HCD=m --- > # CONFIG_USB_ISP116X_HCD is not set 2454,2455c2038 < CONFIG_USB_SL811_HCD=m < CONFIG_USB_SL811_CS=m --- > # CONFIG_USB_SL811_HCD is not set 2477c2060 < CONFIG_USB_STORAGE_USBAT=y --- > # CONFIG_USB_STORAGE_USBAT is not set 2481,2482c2064,2065 < CONFIG_USB_STORAGE_ALAUDA=y < CONFIG_USB_LIBUSUAL=y --- > # CONFIG_USB_STORAGE_ALAUDA is not set > # CONFIG_USB_LIBUSUAL is not set 2487c2070 < CONFIG_USB_HID=m --- > CONFIG_USB_HID=y 2495,2500d2077 < < # < # USB HID Boot Protocol drivers < # < # CONFIG_USB_KBD is not set < # CONFIG_USB_MOUSE is not set 2503c2080 < CONFIG_USB_ACECAD=m --- > # CONFIG_USB_ACECAD is not set 2507c2084 < CONFIG_USB_ITMTOUCH=m --- > # CONFIG_USB_ITMTOUCH is not set 2509c2086 < CONFIG_USB_YEALINK=m --- > # CONFIG_USB_YEALINK is not set 2512,2514c2089,2091 < CONFIG_USB_ATI_REMOTE2=m < CONFIG_USB_KEYSPAN_REMOTE=m < CONFIG_USB_APPLETOUCH=m --- > # CONFIG_USB_ATI_REMOTE2 is not set > # CONFIG_USB_KEYSPAN_REMOTE is not set > # CONFIG_USB_APPLETOUCH is not set 2528c2105 < CONFIG_USB_ET61X251=m --- > # CONFIG_USB_ET61X251 is not set 2548c2125 < CONFIG_USB_NET_GL620A=m --- > # CONFIG_USB_NET_GL620A is not set 2550,2557c2127,2129 < CONFIG_USB_NET_PLUSB=m < CONFIG_USB_NET_RNDIS_HOST=m < CONFIG_USB_NET_CDC_SUBSET=m < CONFIG_USB_ALI_M5632=y < CONFIG_USB_AN2720=y < CONFIG_USB_BELKIN=y < CONFIG_USB_ARMLINUX=y < # CONFIG_USB_EPSON2888 is not set --- > # CONFIG_USB_NET_PLUSB is not set > # CONFIG_USB_NET_RNDIS_HOST is not set > # CONFIG_USB_NET_CDC_SUBSET is not set 2559c2131 < CONFIG_USB_ZD1201=m --- > # CONFIG_USB_ZD1201 is not set 2572,2573c2144,2145 < CONFIG_USB_SERIAL_AIRPRIME=m < CONFIG_USB_SERIAL_ANYDATA=m --- > # CONFIG_USB_SERIAL_AIRPRIME is not set > # CONFIG_USB_SERIAL_ANYDATA is not set 2577,2578c2149,2150 < CONFIG_USB_SERIAL_CP2101=m < CONFIG_USB_SERIAL_CYPRESS_M8=m --- > # CONFIG_USB_SERIAL_CP2101 is not set > # CONFIG_USB_SERIAL_CYPRESS_M8 is not set 2586,2587c2158,2159 < CONFIG_USB_SERIAL_GARMIN=m < CONFIG_USB_SERIAL_IPW=m --- > # CONFIG_USB_SERIAL_GARMIN is not set > # CONFIG_USB_SERIAL_IPW is not set 2606c2178 < CONFIG_USB_SERIAL_HP4X=m --- > # CONFIG_USB_SERIAL_HP4X is not set 2609c2181 < CONFIG_USB_SERIAL_TI=m --- > # CONFIG_USB_SERIAL_TI is not set 2612d2183 < CONFIG_USB_SERIAL_OPTION=m 2620c2191 < CONFIG_USB_EMI26=m --- > # CONFIG_USB_EMI26 is not set 2626,2627c2197,2198 < CONFIG_USB_CYTHERM=m < CONFIG_USB_PHIDGETKIT=m --- > # CONFIG_USB_CYTHERM is not set > # CONFIG_USB_PHIDGETKIT is not set 2629,2632c2200,2202 < CONFIG_USB_IDMOUSE=m < CONFIG_USB_SISUSBVGA=m < CONFIG_USB_SISUSBVGA_CON=y < CONFIG_USB_LD=m --- > # CONFIG_USB_IDMOUSE is not set > # CONFIG_USB_SISUSBVGA is not set > # CONFIG_USB_LD is not set 2640,2642c2210,2212 < CONFIG_USB_CXACRU=m < CONFIG_USB_UEAGLEATM=m < CONFIG_USB_XUSBATM=m --- > # CONFIG_USB_CXACRU is not set > # CONFIG_USB_UEAGLEATM is not set > # CONFIG_USB_XUSBATM is not set 2647,2664c2217 < CONFIG_USB_GADGET=m < # CONFIG_USB_GADGET_DEBUG_FILES is not set < CONFIG_USB_GADGET_SELECTED=y < CONFIG_USB_GADGET_NET2280=y < CONFIG_USB_NET2280=m < # CONFIG_USB_GADGET_PXA2XX is not set < # CONFIG_USB_GADGET_GOKU is not set < # CONFIG_USB_GADGET_LH7A40X is not set < # CONFIG_USB_GADGET_OMAP is not set < # CONFIG_USB_GADGET_DUMMY_HCD is not set < CONFIG_USB_GADGET_DUALSPEED=y < CONFIG_USB_ZERO=m < CONFIG_USB_ETH=m < CONFIG_USB_ETH_RNDIS=y < CONFIG_USB_GADGETFS=m < CONFIG_USB_FILE_STORAGE=m < # CONFIG_USB_FILE_STORAGE_TEST is not set < CONFIG_USB_G_SERIAL=m --- > # CONFIG_USB_GADGET is not set 2669,2672c2222 < CONFIG_MMC=m < # CONFIG_MMC_DEBUG is not set < CONFIG_MMC_BLOCK=m < CONFIG_MMC_WBSD=m --- > # CONFIG_MMC is not set 2681c2231 < # CONFIG_INFINIBAND_MTHCA_DEBUG is not set --- > CONFIG_INFINIBAND_MTHCA_DEBUG=y 2683c2233,2234 < # CONFIG_INFINIBAND_IPOIB_DEBUG is not set --- > CONFIG_INFINIBAND_IPOIB_DEBUG=y > # CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set 2711,2712c2262 < CONFIG_EXT2_FS_XIP=y < CONFIG_FS_XIP=y --- > # CONFIG_EXT2_FS_XIP is not set 2720,2730c2270,2271 < CONFIG_REISERFS_FS=m < # CONFIG_REISERFS_CHECK is not set < # CONFIG_REISERFS_PROC_INFO is not set < CONFIG_REISERFS_FS_XATTR=y < CONFIG_REISERFS_FS_POSIX_ACL=y < CONFIG_REISERFS_FS_SECURITY=y < CONFIG_JFS_FS=m < CONFIG_JFS_POSIX_ACL=y < # CONFIG_JFS_SECURITY is not set < # CONFIG_JFS_DEBUG is not set < CONFIG_JFS_STATISTICS=y --- > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set 2732,2740c2273,2276 < CONFIG_XFS_FS=m < CONFIG_XFS_EXPORT=y < CONFIG_XFS_QUOTA=y < CONFIG_XFS_SECURITY=y < CONFIG_XFS_POSIX_ACL=y < CONFIG_XFS_RT=y < CONFIG_OCFS2_FS=m < CONFIG_MINIX_FS=m < CONFIG_ROMFS_FS=m --- > # CONFIG_XFS_FS is not set > # CONFIG_OCFS2_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_ROMFS_FS is not set 2743,2744c2279,2280 < CONFIG_QFMT_V1=m < CONFIG_QFMT_V2=m --- > # CONFIG_QFMT_V1 is not set > CONFIG_QFMT_V2=y 2747c2283 < CONFIG_AUTOFS_FS=m --- > # CONFIG_AUTOFS_FS is not set 2749c2285 < CONFIG_FUSE_FS=m --- > # CONFIG_FUSE_FS is not set 2754c2290 < CONFIG_ISO9660_FS=m --- > CONFIG_ISO9660_FS=y 2757c2293 < CONFIG_ZISOFS_FS=m --- > CONFIG_ZISOFS_FS=y 2768,2771c2304,2305 < CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" < CONFIG_NTFS_FS=m < # CONFIG_NTFS_DEBUG is not set < # CONFIG_NTFS_RW is not set --- > CONFIG_FAT_DEFAULT_IOCHARSET="ascii" > # CONFIG_NTFS_FS is not set 2780c2314,2315 < # CONFIG_HUGETLB_PAGE is not set --- > CONFIG_HUGETLBFS=y > CONFIG_HUGETLB_PAGE=y 2782,2783c2317,2318 < CONFIG_RELAYFS_FS=m < CONFIG_CONFIGFS_FS=m --- > CONFIG_RELAYFS_FS=y > # CONFIG_CONFIGFS_FS is not set 2788,2790c2323,2324 < CONFIG_ADFS_FS=m < # CONFIG_ADFS_FS_RW is not set < CONFIG_AFFS_FS=m --- > # CONFIG_ADFS_FS is not set > # CONFIG_AFFS_FS is not set 2793,2799c2327,2330 < CONFIG_BEFS_FS=m < # CONFIG_BEFS_DEBUG is not set < CONFIG_BFS_FS=m < CONFIG_EFS_FS=m < CONFIG_JFFS_FS=m < CONFIG_JFFS_FS_VERBOSE=0 < CONFIG_JFFS_PROC_FS=y --- > # CONFIG_BEFS_FS is not set > # CONFIG_BFS_FS is not set > # CONFIG_EFS_FS is not set > # CONFIG_JFFS_FS is not set 2810,2813c2341,2344 < CONFIG_HPFS_FS=m < CONFIG_QNX4FS_FS=m < CONFIG_SYSV_FS=m < CONFIG_UFS_FS=m --- > # CONFIG_HPFS_FS is not set > # CONFIG_QNX4FS_FS is not set > # CONFIG_SYSV_FS is not set > # CONFIG_UFS_FS is not set 2839,2840c2370 < CONFIG_SMB_NLS_DEFAULT=y < CONFIG_SMB_NLS_REMOTE="cp850" --- > # CONFIG_SMB_NLS_DEFAULT is not set 2842,2843c2372 < CONFIG_CIFS_STATS=y < CONFIG_CIFS_STATS2=y --- > # CONFIG_CIFS_STATS is not set 2845c2374 < # CONFIG_CIFS_POSIX is not set --- > CONFIG_CIFS_POSIX=y 2847,2860c2376,2379 < CONFIG_NCP_FS=m < CONFIG_NCPFS_PACKET_SIGNING=y < CONFIG_NCPFS_IOCTL_LOCKING=y < CONFIG_NCPFS_STRONG=y < CONFIG_NCPFS_NFS_NS=y < CONFIG_NCPFS_OS2_NS=y < # CONFIG_NCPFS_SMALLDOS is not set < CONFIG_NCPFS_NLS=y < CONFIG_NCPFS_EXTRAS=y < CONFIG_CODA_FS=m < # CONFIG_CODA_FS_OLD_API is not set < CONFIG_AFS_FS=m < CONFIG_RXRPC=m < CONFIG_9P_FS=m --- > # CONFIG_NCP_FS is not set > # CONFIG_CODA_FS is not set > # CONFIG_AFS_FS is not set > # CONFIG_9P_FS is not set 2869c2388 < CONFIG_ATARI_PARTITION=y --- > # CONFIG_ATARI_PARTITION is not set 2873c2392 < # CONFIG_MINIX_SUBPARTITION is not set --- > CONFIG_MINIX_SUBPARTITION=y 2876,2877c2395 < CONFIG_LDM_PARTITION=y < # CONFIG_LDM_DEBUG is not set --- > # CONFIG_LDM_PARTITION is not set 2879c2397 < CONFIG_ULTRIX_PARTITION=y --- > # CONFIG_ULTRIX_PARTITION is not set 2881c2399 < CONFIG_KARMA_PARTITION=y --- > # CONFIG_KARMA_PARTITION is not set 2889c2407 < CONFIG_NLS_CODEPAGE_437=m --- > CONFIG_NLS_CODEPAGE_437=y 2912c2430 < CONFIG_NLS_ASCII=m --- > CONFIG_NLS_ASCII=y 2931,2932c2449,2451 < # CONFIG_PROFILING is not set < # CONFIG_KPROBES is not set --- > CONFIG_PROFILING=y > CONFIG_OPROFILE=m > CONFIG_KPROBES=y 2940c2459 < CONFIG_LOG_BUF_SHIFT=14 --- > CONFIG_LOG_BUF_SHIFT=17 2944,2946c2463,2465 < # CONFIG_DEBUG_MUTEXES is not set < # CONFIG_DEBUG_SPINLOCK is not set < # CONFIG_DEBUG_SPINLOCK_SLEEP is not set --- > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_SPINLOCK_SLEEP=y 2948c2467 < # CONFIG_DEBUG_HIGHMEM is not set --- > CONFIG_DEBUG_HIGHMEM=y 2950c2469 < # CONFIG_DEBUG_INFO is not set --- > CONFIG_DEBUG_INFO=y 2958c2477 < # CONFIG_DEBUG_STACK_USAGE is not set --- > CONFIG_DEBUG_STACK_USAGE=y 2961c2480 < # CONFIG_4KSTACKS is not set --- > CONFIG_4KSTACKS=y 2969c2488 < # CONFIG_KEYS_DEBUG_PROC_KEYS is not set --- > CONFIG_KEYS_DEBUG_PROC_KEYS=y 2974,2976c2493,2501 < CONFIG_SECURITY_ROOTPLUG=m < CONFIG_SECURITY_SECLVL=m < # CONFIG_SECURITY_SELINUX is not set --- > # CONFIG_SECURITY_ROOTPLUG is not set > # CONFIG_SECURITY_SECLVL is not set > CONFIG_SECURITY_SELINUX=y > CONFIG_SECURITY_SELINUX_BOOTPARAM=y > CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 > CONFIG_SECURITY_SELINUX_DISABLE=y > CONFIG_SECURITY_SELINUX_DEVELOP=y > CONFIG_SECURITY_SELINUX_AVC_STATS=y > CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 2986c2511 < CONFIG_CRYPTO_SHA1=m --- > CONFIG_CRYPTO_SHA1=y 2990c2515 < CONFIG_CRYPTO_TGR192=m --- > # CONFIG_CRYPTO_TGR192 is not set 3002c2527 < CONFIG_CRYPTO_ANUBIS=m --- > # CONFIG_CRYPTO_ANUBIS is not set 3006c2531 < CONFIG_CRYPTO_TEST=m --- > # CONFIG_CRYPTO_TEST is not set 3012,3051d2536 < CONFIG_XEN=y < CONFIG_XEN_INTERFACE_VERSION=0x00030203 < < # < # XEN < # < CONFIG_XEN_PRIVILEGED_GUEST=y < # CONFIG_XEN_UNPRIVILEGED_GUEST is not set < CONFIG_XEN_PRIVCMD=y < CONFIG_XEN_XENBUS_DEV=y < CONFIG_XEN_BACKEND=y < CONFIG_XEN_BLKDEV_BACKEND=y < CONFIG_XEN_BLKDEV_TAP=y < CONFIG_XEN_NETDEV_BACKEND=y < # CONFIG_XEN_NETDEV_PIPELINED_TRANSMITTER is not set < CONFIG_XEN_NETDEV_LOOPBACK=y < CONFIG_XEN_PCIDEV_BACKEND=m < CONFIG_XEN_PCIDEV_BACKEND_VPCI=y < # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set < # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set < # CONFIG_XEN_PCIDEV_BE_DEBUG is not set < # CONFIG_XEN_TPMDEV_BACKEND is not set < CONFIG_XEN_BLKDEV_FRONTEND=y < CONFIG_XEN_NETDEV_FRONTEND=y < CONFIG_XEN_SCRUB_PAGES=y < CONFIG_XEN_DISABLE_SERIAL=y < CONFIG_XEN_SYSFS=y < CONFIG_XEN_COMPAT_030002_AND_LATER=y < # CONFIG_XEN_COMPAT_LATEST_ONLY is not set < CONFIG_XEN_COMPAT_030002=y < CONFIG_HAVE_ARCH_ALLOC_SKB=y < CONFIG_HAVE_ARCH_DEV_ALLOC_SKB=y < CONFIG_HAVE_IRQ_IGNORE_UNHANDLED=y < CONFIG_NO_IDLE_HZ=y < CONFIG_XEN_UTIL=y < CONFIG_XEN_BALLOON=y < CONFIG_XEN_DEVMEM=y < CONFIG_XEN_SKBUFF=y < CONFIG_XEN_REBOOT=y < CONFIG_XEN_SMPBOOT=y 3057c2542 < CONFIG_CRC16=m --- > # CONFIG_CRC16 is not set 3060c2545 < CONFIG_ZLIB_INFLATE=m --- > CONFIG_ZLIB_INFLATE=y 3062,3067d2546 < CONFIG_REED_SOLOMON=m < CONFIG_REED_SOLOMON_DEC16=y < CONFIG_TEXTSEARCH=y < CONFIG_TEXTSEARCH_KMP=m < CONFIG_TEXTSEARCH_BM=m < CONFIG_TEXTSEARCH_FSM=m 3070,3071d2548 < CONFIG_GENERIC_PENDING_IRQ=y < CONFIG_X86_SMP=y 3073,3075d2549 < CONFIG_X86_TRAMPOLINE=y < CONFIG_X86_NO_TSS=y < CONFIG_X86_NO_IDT=y [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 18:23 ` Liang Yang @ 2006-11-07 18:40 ` George Dunlap 2006-11-07 18:46 ` Liang Yang 0 siblings, 1 reply; 16+ messages in thread From: George Dunlap @ 2006-11-07 18:40 UTC (permalink / raw) To: Liang Yang; +Cc: Ian Pratt, xen-devel, Emmanuel Ackaouy, John Byrne It looks like you're using totally different disk schedulers: 90c87 < CONFIG_DEFAULT_CFQ=y --- > # CONFIG_DEFAULT_CFQ is not set 92c89 < CONFIG_DEFAULT_IOSCHED="cfq" --- > CONFIG_DEFAULT_IOSCHED="anticipatory" Try changing them both to the same thing, and seeing what happens... -George On 11/7/06, Liang Yang <multisyncfe991@hotmail.com> wrote: > Attached is the diff of the two kernel configs. > > ----- Original Message ----- > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > To: "Liang Yang" <yangliang_mr@hotmail.com>; "John Byrne" > <john.l.byrne@hp.com> > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> > Sent: Tuesday, November 07, 2006 11:15 AM > Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: > [Xen-devel] Direct I/O to domU seeing a 30% performance hit > > > > I already set dom0_max_vcpus=1 for domain0 when I was doing testing. > Also, > > Linux native kernel and domU kernel are all compiled as Uni-Processor > > mode.All the testing for Linux native, domain0 and domainU are exactly > the > > same. All used Linux kernel 2.6.16.29. > > Please could you post a 'diff' of the two kernel configs. > > It might be worth diff'ing the boot messages in both cases too. > > Thanks, > Ian > > > > Regards, > > > > Liang > > > > ----- Original Message ----- > > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > > To: "Liang Yang" <multisyncfe991@hotmail.com>; "John Byrne" > > <john.l.byrne@hp.com> > > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > > <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> > > Sent: Tuesday, November 07, 2006 11:06 AM > > Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen > DomU. > > Re: > > [Xen-devel] Direct I/O to domU seeing a 30% performance hit > > > > > > > I'm also doing some performance analysis about Linux native, dom0 > and > > domU > > > (para-virtualized). Here are some brief comparison for 256K > sequential > > > read/write. The testing is done using for JBOD based on 8 Maxtor SAS > > Atlas > > > 2 > > > 15K drives with LSI SAS HBA. > > > > > > 256K Sequential Read > > > Linux Native: 559.6MB/s > > > Xen Domain0: 423.3MB/s > > > Xen DomainU: 555.9MB/s > > > > This doesn't make a lot of sense. Only thing I can think of is that > > there must be some extra prefetching going on in the domU case. It > still > > doesn't explain why the dom0 result is so much worse than native. > > > > It might be worth repeating with both native and dom0 boot with > > maxcpus=1. > > > > Are you using near-identical kernels in both cases? Same drivers, same > > part of the disk for the tests, etc? > > > > How are you doing the measurement? A timed 'dd'? > > > > Ian > > > > > > > 256K Sequential Write > > > Linux Native: 668.9MB/s > > > Xen Domain0: 708.7MB/s > > > Xen DomainU: 373.5MB/s > > > > > > Just two questions: > > > > > > It seems para-virtualized DomU outperform Dom0 in terms of > sequential > > read > > > and is very to Linux native performance. However, DomU does show > poor > > (only > > > 50%) sequential write performance compared with Linux native and > Dom0. > > > > > > Could you explain some reason behind this? > > > > > > Thanks, > > > > > > Liang > > > > > > > > > ----- Original Message ----- > > > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > > > To: "John Byrne" <john.l.byrne@hp.com> > > > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > > > <ack@xensource.com> > > > Sent: Tuesday, November 07, 2006 10:20 AM > > > Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance > > hit > > > > > > > > > > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > > > > performance of the two should be different. The obvious asymmetry > is > > > the > > > > disk. Since the disk isn't direct, any disk I/O by the domU would > > > > certainly impact dom0, but I don't think there should be much, if > > any. > > > I > > > > did run a dom0 test with the domU started, but idle and there was > no > > > > real change to dom0's numbers. > > > > > > > > What's the best way to gather information about what is going on > > with > > > > the domains without perturbing them? (Or, at least, perturbing > > > everyone > > > > equally.) > > > > > > > > As to the test, I am running netperf 2.4.1 on an outside machine > to > > > the > > > > dom0 and the domU. (So the doms are running the netserver > portion.) > > I > > > > was originally running it in the doms to the outside machine, but > > when > > > > the bad numbers showed up I moved it to the outside machine > because > > I > > > > wondered if the bad numbers were due to something happening to the > > > > system time in domU. The numbers is the "outside" test to domU > look > > > worse. > > > > > > > > > It might be worth checking that there's no interrupt sharing > > happening. > > > While running the test against the domU, see how much CPU dom0 burns > > in > > > the same period using 'xm vcpu-list'. > > > > > > To keep things simple, have dom0 and domU as uniprocessor guests. > > > > > > Ian > > > > > > > > > > Ian Pratt wrote: > > > > > > > > > >> There have been a couple of network receive throughput > > > > >> performance regressions to domUs over time that were > > > > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > > > > > > > The report was (I believe) with a NIC directly assigned to the > > domU, > > > so > > > > > not using netfront/back at all. > > > > > > > > > > John: please can you give more details on your config. > > > > > > > > > > Ian > > > > > > > > > >> Are you seeing any dropped packets on the vif associated with > > > > >> your domU in your dom0? If so, propagating changeset > > > > >> 11861 from unstable may help: > > > > >> > > > > >> changeset: 11861:637eace6d5c6 > > > > >> user: kfraser@localhost.localdomain > > > > >> date: Mon Oct 23 11:20:37 2006 +0100 > > > > >> summary: [NET] back: Fix packet queuing so that packets > > > > >> are drained if the > > > > >> > > > > >> > > > > >> In the past, we also had receive throughput issues to domUs > > > > >> that were due to socket buffer size logic but those were > > > > >> fixed a while ago. > > > > >> > > > > >> Can you send netstat -i output from dom0? > > > > >> > > > > >> Emmanuel. > > > > >> > > > > >> > > > > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > > > >>> I was asked to test direct I/O to a PV domU. Since, I had a > > system > > > > >>> with two NICs, I gave one to a domU and one dom0. (Each is > > > > >> running the > > > > >>> same > > > > >>> kernel: xen 3.0.3 x86_64.) > > > > >>> > > > > >>> I'm running netperf from an outside system to the domU and > > > > >> dom0 and I > > > > >>> am seeing 30% less throughput for the domU vs dom0. > > > > >>> > > > > >>> Is this to be expected? If so, why? If not, does anyone > > > > >> have a guess > > > > >>> as to what I might be doing wrong or what the issue might be? > > > > >>> > > > > >>> Thanks, > > > > >>> > > > > >>> John Byrne > > > > >> _______________________________________________ > > > > >> Xen-devel mailing list > > > > >> Xen-devel@lists.xensource.com > > > > >> http://lists.xensource.com/xen-devel > > > > >> > > > > > > > > > > _______________________________________________ > > > > > Xen-devel mailing list > > > > > Xen-devel@lists.xensource.com > > > > > http://lists.xensource.com/xen-devel > > > > > > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 18:40 ` George Dunlap @ 2006-11-07 18:46 ` Liang Yang 0 siblings, 0 replies; 16+ messages in thread From: Liang Yang @ 2006-11-07 18:46 UTC (permalink / raw) To: George Dunlap; +Cc: Ian Pratt, xen-devel, Emmanuel Ackaouy, John Byrne I already changed the Linux I/O scheduler for all block devices to Anticipatory before I start the testing. This is done runtime. Liang ----- Original Message ----- From: "George Dunlap" <gdunlap@xensource.com> To: "Liang Yang" <multisyncfe991@hotmail.com> Cc: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk>; "John Byrne" <john.l.byrne@hp.com>; "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" <ack@xensource.com> Sent: Tuesday, November 07, 2006 11:40 AM Subject: Re: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > It looks like you're using totally different disk schedulers: > > 90c87 > < CONFIG_DEFAULT_CFQ=y > --- >> # CONFIG_DEFAULT_CFQ is not set > 92c89 > < CONFIG_DEFAULT_IOSCHED="cfq" > --- >> CONFIG_DEFAULT_IOSCHED="anticipatory" > > Try changing them both to the same thing, and seeing what happens... > > -George > > On 11/7/06, Liang Yang <multisyncfe991@hotmail.com> wrote: >> Attached is the diff of the two kernel configs. >> >> ----- Original Message ----- >> From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> >> To: "Liang Yang" <yangliang_mr@hotmail.com>; "John Byrne" >> <john.l.byrne@hp.com> >> Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" >> <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> >> Sent: Tuesday, November 07, 2006 11:15 AM >> Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. >> Re: >> [Xen-devel] Direct I/O to domU seeing a 30% performance hit >> >> >> > I already set dom0_max_vcpus=1 for domain0 when I was doing testing. >> Also, >> > Linux native kernel and domU kernel are all compiled as Uni-Processor >> > mode.All the testing for Linux native, domain0 and domainU are exactly >> the >> > same. All used Linux kernel 2.6.16.29. >> >> Please could you post a 'diff' of the two kernel configs. >> >> It might be worth diff'ing the boot messages in both cases too. >> >> Thanks, >> Ian >> >> >> > Regards, >> > >> > Liang >> > >> > ----- Original Message ----- >> > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> >> > To: "Liang Yang" <multisyncfe991@hotmail.com>; "John Byrne" >> > <john.l.byrne@hp.com> >> > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" >> > <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> >> > Sent: Tuesday, November 07, 2006 11:06 AM >> > Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen >> DomU. >> > Re: >> > [Xen-devel] Direct I/O to domU seeing a 30% performance hit >> > >> > >> > > I'm also doing some performance analysis about Linux native, dom0 >> and >> > domU >> > > (para-virtualized). Here are some brief comparison for 256K >> sequential >> > > read/write. The testing is done using for JBOD based on 8 Maxtor SAS >> > Atlas >> > > 2 >> > > 15K drives with LSI SAS HBA. >> > > >> > > 256K Sequential Read >> > > Linux Native: 559.6MB/s >> > > Xen Domain0: 423.3MB/s >> > > Xen DomainU: 555.9MB/s >> > >> > This doesn't make a lot of sense. Only thing I can think of is that >> > there must be some extra prefetching going on in the domU case. It >> still >> > doesn't explain why the dom0 result is so much worse than native. >> > >> > It might be worth repeating with both native and dom0 boot with >> > maxcpus=1. >> > >> > Are you using near-identical kernels in both cases? Same drivers, same >> > part of the disk for the tests, etc? >> > >> > How are you doing the measurement? A timed 'dd'? >> > >> > Ian >> > >> > >> > > 256K Sequential Write >> > > Linux Native: 668.9MB/s >> > > Xen Domain0: 708.7MB/s >> > > Xen DomainU: 373.5MB/s >> > > >> > > Just two questions: >> > > >> > > It seems para-virtualized DomU outperform Dom0 in terms of >> sequential >> > read >> > > and is very to Linux native performance. However, DomU does show >> poor >> > (only >> > > 50%) sequential write performance compared with Linux native and >> Dom0. >> > > >> > > Could you explain some reason behind this? >> > > >> > > Thanks, >> > > >> > > Liang >> > > >> > > >> > > ----- Original Message ----- >> > > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> >> > > To: "John Byrne" <john.l.byrne@hp.com> >> > > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" >> > > <ack@xensource.com> >> > > Sent: Tuesday, November 07, 2006 10:20 AM >> > > Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance >> > hit >> > > >> > > >> > > > Both dom0 and the domU are SLES 10, so I don't know why the "idle" >> > > > performance of the two should be different. The obvious asymmetry >> is >> > > the >> > > > disk. Since the disk isn't direct, any disk I/O by the domU would >> > > > certainly impact dom0, but I don't think there should be much, if >> > any. >> > > I >> > > > did run a dom0 test with the domU started, but idle and there was >> no >> > > > real change to dom0's numbers. >> > > > >> > > > What's the best way to gather information about what is going on >> > with >> > > > the domains without perturbing them? (Or, at least, perturbing >> > > everyone >> > > > equally.) >> > > > >> > > > As to the test, I am running netperf 2.4.1 on an outside machine >> to >> > > the >> > > > dom0 and the domU. (So the doms are running the netserver >> portion.) >> > I >> > > > was originally running it in the doms to the outside machine, but >> > when >> > > > the bad numbers showed up I moved it to the outside machine >> because >> > I >> > > > wondered if the bad numbers were due to something happening to the >> > > > system time in domU. The numbers is the "outside" test to domU >> look >> > > worse. >> > > >> > > >> > > It might be worth checking that there's no interrupt sharing >> > happening. >> > > While running the test against the domU, see how much CPU dom0 burns >> > in >> > > the same period using 'xm vcpu-list'. >> > > >> > > To keep things simple, have dom0 and domU as uniprocessor guests. >> > > >> > > Ian >> > > >> > > >> > > > Ian Pratt wrote: >> > > > > >> > > > >> There have been a couple of network receive throughput >> > > > >> performance regressions to domUs over time that were >> > > > >> subsequently fixed. I think one may have crept in to 3.0.3. >> > > > > >> > > > > The report was (I believe) with a NIC directly assigned to the >> > domU, >> > > so >> > > > > not using netfront/back at all. >> > > > > >> > > > > John: please can you give more details on your config. >> > > > > >> > > > > Ian >> > > > > >> > > > >> Are you seeing any dropped packets on the vif associated with >> > > > >> your domU in your dom0? If so, propagating changeset >> > > > >> 11861 from unstable may help: >> > > > >> >> > > > >> changeset: 11861:637eace6d5c6 >> > > > >> user: kfraser@localhost.localdomain >> > > > >> date: Mon Oct 23 11:20:37 2006 +0100 >> > > > >> summary: [NET] back: Fix packet queuing so that packets >> > > > >> are drained if the >> > > > >> >> > > > >> >> > > > >> In the past, we also had receive throughput issues to domUs >> > > > >> that were due to socket buffer size logic but those were >> > > > >> fixed a while ago. >> > > > >> >> > > > >> Can you send netstat -i output from dom0? >> > > > >> >> > > > >> Emmanuel. >> > > > >> >> > > > >> >> > > > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: >> > > > >>> I was asked to test direct I/O to a PV domU. Since, I had a >> > system >> > > > >>> with two NICs, I gave one to a domU and one dom0. (Each is >> > > > >> running the >> > > > >>> same >> > > > >>> kernel: xen 3.0.3 x86_64.) >> > > > >>> >> > > > >>> I'm running netperf from an outside system to the domU and >> > > > >> dom0 and I >> > > > >>> am seeing 30% less throughput for the domU vs dom0. >> > > > >>> >> > > > >>> Is this to be expected? If so, why? If not, does anyone >> > > > >> have a guess >> > > > >>> as to what I might be doing wrong or what the issue might be? >> > > > >>> >> > > > >>> Thanks, >> > > > >>> >> > > > >>> John Byrne >> > > > >> _______________________________________________ >> > > > >> Xen-devel mailing list >> > > > >> Xen-devel@lists.xensource.com >> > > > >> http://lists.xensource.com/xen-devel >> > > > >> >> > > > > >> > > > > _______________________________________________ >> > > > > Xen-devel mailing list >> > > > > Xen-devel@lists.xensource.com >> > > > > http://lists.xensource.com/xen-devel >> > > > > >> > > >> > > >> > > _______________________________________________ >> > > Xen-devel mailing list >> > > Xen-devel@lists.xensource.com >> > > http://lists.xensource.com/xen-devel >> > >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> >> >> > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Using IOMeter. Re: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 18:06 ` Ian Pratt 2006-11-07 18:10 ` Liang Yang @ 2006-11-07 18:14 ` Liang Yang 1 sibling, 0 replies; 16+ messages in thread From: Liang Yang @ 2006-11-07 18:14 UTC (permalink / raw) To: Ian Pratt, John Byrne; +Cc: xen-devel, Emmanuel Ackaouy Hi Ian, I forget to mention the benchmark tool I was using is IOMeter which support setting up larger queue depth of outstanding I/O to saturate the disk. Single dd will not saturate the disk. I already set dom0_max_vcpus=1 for domain0 when I was doing testing. Also, Linux native kernel and domU kernel are all compiled as Uni-Processor mode.All the testing for Linux native, domain0 and domainU are exactly the same. All used Linux kernel 2.6.16.29. Regards, Liang ----- Original Message ----- From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> To: "Liang Yang" <multisyncfe991@hotmail.com>; "John Byrne" <john.l.byrne@hp.com> Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" <ack@xensource.com>; <ian.pratt@cl.cam.ac.uk> Sent: Tuesday, November 07, 2006 11:06 AM Subject: RE: Performance data of Linux native vs. Xen Dom0 and Xen DomU. Re: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > I'm also doing some performance analysis about Linux native, dom0 and domU > (para-virtualized). Here are some brief comparison for 256K sequential > read/write. The testing is done using for JBOD based on 8 Maxtor SAS Atlas > 2 > 15K drives with LSI SAS HBA. > > 256K Sequential Read > Linux Native: 559.6MB/s > Xen Domain0: 423.3MB/s > Xen DomainU: 555.9MB/s This doesn't make a lot of sense. Only thing I can think of is that there must be some extra prefetching going on in the domU case. It still doesn't explain why the dom0 result is so much worse than native. It might be worth repeating with both native and dom0 boot with maxcpus=1. Are you using near-identical kernels in both cases? Same drivers, same part of the disk for the tests, etc? How are you doing the measurement? A timed 'dd'? Ian > 256K Sequential Write > Linux Native: 668.9MB/s > Xen Domain0: 708.7MB/s > Xen DomainU: 373.5MB/s > > Just two questions: > > It seems para-virtualized DomU outperform Dom0 in terms of sequential read > and is very to Linux native performance. However, DomU does show poor (only > 50%) sequential write performance compared with Linux native and Dom0. > > Could you explain some reason behind this? > > Thanks, > > Liang > > > ----- Original Message ----- > From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> > To: "John Byrne" <john.l.byrne@hp.com> > Cc: "xen-devel" <xen-devel@lists.xensource.com>; "Emmanuel Ackaouy" > <ack@xensource.com> > Sent: Tuesday, November 07, 2006 10:20 AM > Subject: RE: [Xen-devel] Direct I/O to domU seeing a 30% performance hit > > > > Both dom0 and the domU are SLES 10, so I don't know why the "idle" > > performance of the two should be different. The obvious asymmetry is > the > > disk. Since the disk isn't direct, any disk I/O by the domU would > > certainly impact dom0, but I don't think there should be much, if any. > I > > did run a dom0 test with the domU started, but idle and there was no > > real change to dom0's numbers. > > > > What's the best way to gather information about what is going on with > > the domains without perturbing them? (Or, at least, perturbing > everyone > > equally.) > > > > As to the test, I am running netperf 2.4.1 on an outside machine to > the > > dom0 and the domU. (So the doms are running the netserver portion.) I > > was originally running it in the doms to the outside machine, but when > > the bad numbers showed up I moved it to the outside machine because I > > wondered if the bad numbers were due to something happening to the > > system time in domU. The numbers is the "outside" test to domU look > worse. > > > It might be worth checking that there's no interrupt sharing happening. > While running the test against the domU, see how much CPU dom0 burns in > the same period using 'xm vcpu-list'. > > To keep things simple, have dom0 and domU as uniprocessor guests. > > Ian > > > > Ian Pratt wrote: > > > > > >> There have been a couple of network receive throughput > > >> performance regressions to domUs over time that were > > >> subsequently fixed. I think one may have crept in to 3.0.3. > > > > > > The report was (I believe) with a NIC directly assigned to the domU, > so > > > not using netfront/back at all. > > > > > > John: please can you give more details on your config. > > > > > > Ian > > > > > >> Are you seeing any dropped packets on the vif associated with > > >> your domU in your dom0? If so, propagating changeset > > >> 11861 from unstable may help: > > >> > > >> changeset: 11861:637eace6d5c6 > > >> user: kfraser@localhost.localdomain > > >> date: Mon Oct 23 11:20:37 2006 +0100 > > >> summary: [NET] back: Fix packet queuing so that packets > > >> are drained if the > > >> > > >> > > >> In the past, we also had receive throughput issues to domUs > > >> that were due to socket buffer size logic but those were > > >> fixed a while ago. > > >> > > >> Can you send netstat -i output from dom0? > > >> > > >> Emmanuel. > > >> > > >> > > >> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > >>> I was asked to test direct I/O to a PV domU. Since, I had a system > > >>> with two NICs, I gave one to a domU and one dom0. (Each is > > >> running the > > >>> same > > >>> kernel: xen 3.0.3 x86_64.) > > >>> > > >>> I'm running netperf from an outside system to the domU and > > >> dom0 and I > > >>> am seeing 30% less throughput for the domU vs dom0. > > >>> > > >>> Is this to be expected? If so, why? If not, does anyone > > >> have a guess > > >>> as to what I might be doing wrong or what the issue might be? > > >>> > > >>> Thanks, > > >>> > > >>> John Byrne > > >> _______________________________________________ > > >> Xen-devel mailing list > > >> Xen-devel@lists.xensource.com > > >> http://lists.xensource.com/xen-devel > > >> > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 17:20 ` Ian Pratt 2006-11-07 17:40 ` Performance data of Linux native vs. Xen Dom0 and Xen DomU. " Liang Yang @ 2006-11-07 19:17 ` John Byrne 1 sibling, 0 replies; 16+ messages in thread From: John Byrne @ 2006-11-07 19:17 UTC (permalink / raw) To: Ian Pratt; +Cc: xen-devel, Emmanuel Ackaouy Ian, I had screwed up and had a process running in dom0 chewing up CPU in dom0. I thought I had taken care of it. After fixing that, most of the numbers for dom0, domU, and the base SLES kernel are within a couple of tenths of percent of each other. However, there are some fairly large differences in some of the runs where the socket buffers are small. Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 262142 262142 4096 60.00 941.03 base 262142 262142 4096 60.00 939.95 dom0 262142 262142 4096 60.00 937.22 domU 16384 16384 32768 60.00 379.68 base 16384 16384 32768 60.00 350.15 dom0 16384 16384 32768 60.00 367.89 domU In the latter case, the divergence from the base performance is much larger. I assume that when the socket buffers are small, the extra overhead for the interrupts is showing up more because more interrupts are required. Overall, though, the numbers are now acceptable. Thanks for your help. It allowed me to spot my goof. (Sorry about wasting your time though.) One last question: is there an easy way to break out the amount of CPU time spent in the hypervisor? Thanks, John Byrne Ian Pratt wrote: >> Both dom0 and the domU are SLES 10, so I don't know why the "idle" >> performance of the two should be different. The obvious asymmetry is > the >> disk. Since the disk isn't direct, any disk I/O by the domU would >> certainly impact dom0, but I don't think there should be much, if any. > I >> did run a dom0 test with the domU started, but idle and there was no >> real change to dom0's numbers. >> >> What's the best way to gather information about what is going on with >> the domains without perturbing them? (Or, at least, perturbing > everyone >> equally.) >> >> As to the test, I am running netperf 2.4.1 on an outside machine to > the >> dom0 and the domU. (So the doms are running the netserver portion.) I >> was originally running it in the doms to the outside machine, but when >> the bad numbers showed up I moved it to the outside machine because I >> wondered if the bad numbers were due to something happening to the >> system time in domU. The numbers is the "outside" test to domU look > worse. > > > It might be worth checking that there's no interrupt sharing happening. > While running the test against the domU, see how much CPU dom0 burns in > the same period using 'xm vcpu-list'. > > To keep things simple, have dom0 and domU as uniprocessor guests. > > Ian > > >> Ian Pratt wrote: >>>> There have been a couple of network receive throughput >>>> performance regressions to domUs over time that were >>>> subsequently fixed. I think one may have crept in to 3.0.3. >>> The report was (I believe) with a NIC directly assigned to the domU, > so >>> not using netfront/back at all. >>> >>> John: please can you give more details on your config. >>> >>> Ian >>> >>>> Are you seeing any dropped packets on the vif associated with >>>> your domU in your dom0? If so, propagating changeset >>>> 11861 from unstable may help: >>>> >>>> changeset: 11861:637eace6d5c6 >>>> user: kfraser@localhost.localdomain >>>> date: Mon Oct 23 11:20:37 2006 +0100 >>>> summary: [NET] back: Fix packet queuing so that packets >>>> are drained if the >>>> >>>> >>>> In the past, we also had receive throughput issues to domUs >>>> that were due to socket buffer size logic but those were >>>> fixed a while ago. >>>> >>>> Can you send netstat -i output from dom0? >>>> >>>> Emmanuel. >>>> >>>> >>>> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: >>>>> I was asked to test direct I/O to a PV domU. Since, I had a system >>>>> with two NICs, I gave one to a domU and one dom0. (Each is >>>> running the >>>>> same >>>>> kernel: xen 3.0.3 x86_64.) >>>>> >>>>> I'm running netperf from an outside system to the domU and >>>> dom0 and I >>>>> am seeing 30% less throughput for the domU vs dom0. >>>>> >>>>> Is this to be expected? If so, why? If not, does anyone >>>> have a guess >>>>> as to what I might be doing wrong or what the issue might be? >>>>> >>>>> Thanks, >>>>> >>>>> John Byrne >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Direct I/O to domU seeing a 30% performance hit @ 2006-11-07 19:24 Ian Pratt 0 siblings, 0 replies; 16+ messages in thread From: Ian Pratt @ 2006-11-07 19:24 UTC (permalink / raw) To: John Byrne; +Cc: xen-devel, Emmanuel Ackaouy > One last question: is there an easy way to break out the > amount of CPU time spent in the hypervisor? It may be possible to configure the CPU perf counters to record the amount of time you spend in ring0. Otherwise, use xen-oprofile for an estimate. Ian > Thanks, > > John Byrne > > > Ian Pratt wrote: > >> Both dom0 and the domU are SLES 10, so I don't know why the "idle" > >> performance of the two should be different. The obvious > asymmetry is > > the > >> disk. Since the disk isn't direct, any disk I/O by the domU would > >> certainly impact dom0, but I don't think there should be > much, if any. > > I > >> did run a dom0 test with the domU started, but idle and > there was no > >> real change to dom0's numbers. > >> > >> What's the best way to gather information about what is > going on with > >> the domains without perturbing them? (Or, at least, perturbing > > everyone > >> equally.) > >> > >> As to the test, I am running netperf 2.4.1 on an outside machine to > > the > >> dom0 and the domU. (So the doms are running the netserver > portion.) I > >> was originally running it in the doms to the outside machine, but > >> when the bad numbers showed up I moved it to the outside machine > >> because I wondered if the bad numbers were due to > something happening > >> to the system time in domU. The numbers is the "outside" > test to domU > >> look > > worse. > > > > > > It might be worth checking that there's no interrupt > sharing happening. > > While running the test against the domU, see how much CPU > dom0 burns > > in the same period using 'xm vcpu-list'. > > > > To keep things simple, have dom0 and domU as uniprocessor guests. > > > > Ian > > > > > >> Ian Pratt wrote: > >>>> There have been a couple of network receive throughput > performance > >>>> regressions to domUs over time that were subsequently fixed. I > >>>> think one may have crept in to 3.0.3. > >>> The report was (I believe) with a NIC directly assigned > to the domU, > > so > >>> not using netfront/back at all. > >>> > >>> John: please can you give more details on your config. > >>> > >>> Ian > >>> > >>>> Are you seeing any dropped packets on the vif associated > with your > >>>> domU in your dom0? If so, propagating changeset > >>>> 11861 from unstable may help: > >>>> > >>>> changeset: 11861:637eace6d5c6 > >>>> user: kfraser@localhost.localdomain > >>>> date: Mon Oct 23 11:20:37 2006 +0100 > >>>> summary: [NET] back: Fix packet queuing so that packets > >>>> are drained if the > >>>> > >>>> > >>>> In the past, we also had receive throughput issues to domUs that > >>>> were due to socket buffer size logic but those were > fixed a while > >>>> ago. > >>>> > >>>> Can you send netstat -i output from dom0? > >>>> > >>>> Emmanuel. > >>>> > >>>> > >>>> On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > >>>>> I was asked to test direct I/O to a PV domU. Since, I > had a system > >>>>> with two NICs, I gave one to a domU and one dom0. (Each is > >>>> running the > >>>>> same > >>>>> kernel: xen 3.0.3 x86_64.) > >>>>> > >>>>> I'm running netperf from an outside system to the domU and > >>>> dom0 and I > >>>>> am seeing 30% less throughput for the domU vs dom0. > >>>>> > >>>>> Is this to be expected? If so, why? If not, does anyone > >>>> have a guess > >>>>> as to what I might be doing wrong or what the issue might be? > >>>>> > >>>>> Thanks, > >>>>> > >>>>> John Byrne > >>>> _______________________________________________ > >>>> Xen-devel mailing list > >>>> Xen-devel@lists.xensource.com > >>>> http://lists.xensource.com/xen-devel > >>>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xensource.com > >>> http://lists.xensource.com/xen-devel > >>> > > > > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Direct I/O to domU seeing a 30% performance hit @ 2006-11-07 5:55 John Byrne 2006-11-07 11:09 ` Ian Pratt 2006-11-07 11:37 ` Emmanuel Ackaouy 0 siblings, 2 replies; 16+ messages in thread From: John Byrne @ 2006-11-07 5:55 UTC (permalink / raw) To: xen-devel I was asked to test direct I/O to a PV domU. Since, I had a system with two NICs, I gave one to a domU and one dom0. (Each is running the same kernel: xen 3.0.3 x86_64.) I'm running netperf from an outside system to the domU and dom0 and I am seeing 30% less throughput for the domU vs dom0. Is this to be expected? If so, why? If not, does anyone have a guess as to what I might be doing wrong or what the issue might be? Thanks, John Byrne ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Direct I/O to domU seeing a 30% performance hit 2006-11-07 5:55 John Byrne @ 2006-11-07 11:09 ` Ian Pratt 2006-11-07 11:37 ` Emmanuel Ackaouy 1 sibling, 0 replies; 16+ messages in thread From: Ian Pratt @ 2006-11-07 11:09 UTC (permalink / raw) To: John Byrne, xen-devel > I was asked to test direct I/O to a PV domU. Since, I had a system with > two NICs, I gave one to a domU and one dom0. (Each is running the same > kernel: xen 3.0.3 x86_64.) > > I'm running netperf from an outside system to the domU and dom0 and I am > seeing 30% less throughput for the domU vs dom0. That doesn't make sense -- they should be identical. Is there other stuff going on in the system that could be taking CPU time away from the domU? Ian > Is this to be expected? If so, why? If not, does anyone have a guess as > to what I might be doing wrong or what the issue might be? > > Thanks, > > John Byrne > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Direct I/O to domU seeing a 30% performance hit 2006-11-07 5:55 John Byrne 2006-11-07 11:09 ` Ian Pratt @ 2006-11-07 11:37 ` Emmanuel Ackaouy 1 sibling, 0 replies; 16+ messages in thread From: Emmanuel Ackaouy @ 2006-11-07 11:37 UTC (permalink / raw) To: John Byrne; +Cc: xen-devel There have been a couple of network receive throughput performance regressions to domUs over time that were subsequently fixed. I think one may have crept in to 3.0.3. Are you seeing any dropped packets on the vif associated with your domU in your dom0? If so, propagating changeset 11861 from unstable may help: changeset: 11861:637eace6d5c6 user: kfraser@localhost.localdomain date: Mon Oct 23 11:20:37 2006 +0100 summary: [NET] back: Fix packet queuing so that packets are drained if the In the past, we also had receive throughput issues to domUs that were due to socket buffer size logic but those were fixed a while ago. Can you send netstat -i output from dom0? Emmanuel. On Mon, Nov 06, 2006 at 09:55:17PM -0800, John Byrne wrote: > > I was asked to test direct I/O to a PV domU. Since, I had a system with > two NICs, I gave one to a domU and one dom0. (Each is running the same > kernel: xen 3.0.3 x86_64.) > > I'm running netperf from an outside system to the domU and dom0 and I am > seeing 30% less throughput for the domU vs dom0. > > Is this to be expected? If so, why? If not, does anyone have a guess as > to what I might be doing wrong or what the issue might be? > > Thanks, > > John Byrne ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-11-07 19:24 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-11-07 12:18 Direct I/O to domU seeing a 30% performance hit Ian Pratt 2006-11-07 16:44 ` John Byrne 2006-11-07 17:20 ` Ian Pratt 2006-11-07 17:40 ` Performance data of Linux native vs. Xen Dom0 and Xen DomU. " Liang Yang 2006-11-07 18:06 ` Ian Pratt 2006-11-07 18:10 ` Liang Yang 2006-11-07 18:15 ` Ian Pratt 2006-11-07 18:23 ` Liang Yang 2006-11-07 18:40 ` George Dunlap 2006-11-07 18:46 ` Liang Yang 2006-11-07 18:14 ` Using IOMeter. " Liang Yang 2006-11-07 19:17 ` John Byrne -- strict thread matches above, loose matches on Subject: below -- 2006-11-07 19:24 Ian Pratt 2006-11-07 5:55 John Byrne 2006-11-07 11:09 ` Ian Pratt 2006-11-07 11:37 ` Emmanuel Ackaouy
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.