> if you could temporarly run a 9atom kernel, cpu% dd -if /dev/sdU0.0/data -of /dev/null -count 1024 -bs 65536
/dev/irqalloc yields trap irq delta count delta cycles type name 35 3 27648 510854000 i8259 usbehci which doesn't seem extraordinary. and nothing else is huge either. mpirq doesn't appear to exist in #P the whole transfer takes about 8% longer on 9atom. > > if i force polling, it's a little faster: 0.01u 0.45s 17.70r > That's interesting - it shouldn't make a difference unless there's > something wrong with the controller or the driver. What did you do to > force polling? added 'ctrl->poll.must = 1' to init in usbehci.c > Yes, I think you're right - system cputime will only be incremented for > a running process. But you can watch the last column of /dev/sysstat > (or use 'stats -I') to see the percentage of time spent in interrupt > handlers. interrupt time is quite low/very low... (olpc / intel) > How about number of interrupts? Erik's theory was that you were > getting too many of these. interrupt count is very low/moderate... (olpc / intel) my working theory is that i'm getting all the interrupts, but not soon enough... the fascinating piece is that the olpc and the pc with intel ehc take just about the same amount of time. and a different usb flash device doesn't change it (which was expected as usb/ether seems to suffer also). enjoy, tristan -- All original matter is hereby placed immediately under the public domain.
