Re: io scheduler silly question perhaps..
On 7/29/05, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Jul 28 2005, Nate Diller wrote: > > Try benchmarking Anticipatory or Deadline against Noop, preferably > > with your actual workload. Noop is probably what you want, since > > there is not much use in avoiding large "seeks". It could be though > > that request merging, which the non-noop schedulers all perform, willl > > cause Noop to lose. I haven't tried any I/O scheduler benchmarks with > > flash, but perhaps we need a simple "merge only" scheduler for this > > sort of thing. > > > > Let me know what the results are. > > deadline is the appropriate choice, you could still have read starvation > issues with noop. anticipatory doesn't make any sense, as the device has > no seek penalty. I'm not sure I understand your concern with noop. even if there were writes in the queue (he said there were none/few) i don't see how read starvation could occur with a FIFO. also, I have read that for large flash devices, there is a (small) seek penalty, but that it's relatively constant for large vs. small seeks. can someone elaborate on that? so dave, try deadline vs noop and let us know what you get. also, are you concerned with CPU use? > > and hey, don't top post! now we lost daves original mail. yeah, you're right, so much for gmail "quick reply" NATE > > -- > Jens Axboe > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: io scheduler silly question perhaps..
On Thu, Jul 28 2005, Nate Diller wrote: > Try benchmarking Anticipatory or Deadline against Noop, preferably > with your actual workload. Noop is probably what you want, since > there is not much use in avoiding large "seeks". It could be though > that request merging, which the non-noop schedulers all perform, willl > cause Noop to lose. I haven't tried any I/O scheduler benchmarks with > flash, but perhaps we need a simple "merge only" scheduler for this > sort of thing. > > Let me know what the results are. deadline is the appropriate choice, you could still have read starvation issues with noop. anticipatory doesn't make any sense, as the device has no seek penalty. and hey, don't top post! now we lost daves original mail. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: io scheduler silly question perhaps..
On Thu, Jul 28 2005, Nate Diller wrote: Try benchmarking Anticipatory or Deadline against Noop, preferably with your actual workload. Noop is probably what you want, since there is not much use in avoiding large seeks. It could be though that request merging, which the non-noop schedulers all perform, willl cause Noop to lose. I haven't tried any I/O scheduler benchmarks with flash, but perhaps we need a simple merge only scheduler for this sort of thing. Let me know what the results are. deadline is the appropriate choice, you could still have read starvation issues with noop. anticipatory doesn't make any sense, as the device has no seek penalty. and hey, don't top post! now we lost daves original mail. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: io scheduler silly question perhaps..
On 7/29/05, Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Jul 28 2005, Nate Diller wrote: Try benchmarking Anticipatory or Deadline against Noop, preferably with your actual workload. Noop is probably what you want, since there is not much use in avoiding large seeks. It could be though that request merging, which the non-noop schedulers all perform, willl cause Noop to lose. I haven't tried any I/O scheduler benchmarks with flash, but perhaps we need a simple merge only scheduler for this sort of thing. Let me know what the results are. deadline is the appropriate choice, you could still have read starvation issues with noop. anticipatory doesn't make any sense, as the device has no seek penalty. I'm not sure I understand your concern with noop. even if there were writes in the queue (he said there were none/few) i don't see how read starvation could occur with a FIFO. also, I have read that for large flash devices, there is a (small) seek penalty, but that it's relatively constant for large vs. small seeks. can someone elaborate on that? so dave, try deadline vs noop and let us know what you get. also, are you concerned with CPU use? and hey, don't top post! now we lost daves original mail. yeah, you're right, so much for gmail quick reply NATE -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: io scheduler silly question perhaps..
Try benchmarking Anticipatory or Deadline against Noop, preferably with your actual workload. Noop is probably what you want, since there is not much use in avoiding large "seeks". It could be though that request merging, which the non-noop schedulers all perform, willl cause Noop to lose. I haven't tried any I/O scheduler benchmarks with flash, but perhaps we need a simple "merge only" scheduler for this sort of thing. Let me know what the results are. NATE On 7/28/05, Dave Airlie <[EMAIL PROTECTED]> wrote: > > I have an embedded system which has two read-only flash devices (one a > PIO ATA flash disk, and one MDMA capable flash) > > As I'm doing no writing in this system and most of my reads are sequential > (streaming movies or images) would my choice of io scheduler be very > important? > > Regards, > Dave. > > -- > David Airlie, Software Engineer > http://www.skynet.ie/~airlied / airlied at skynet.ie > Linux kernel - DRI, VAX / pam_smb / ILUG > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
io scheduler silly question perhaps..
I have an embedded system which has two read-only flash devices (one a PIO ATA flash disk, and one MDMA capable flash) As I'm doing no writing in this system and most of my reads are sequential (streaming movies or images) would my choice of io scheduler be very important? Regards, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
io scheduler silly question perhaps..
I have an embedded system which has two read-only flash devices (one a PIO ATA flash disk, and one MDMA capable flash) As I'm doing no writing in this system and most of my reads are sequential (streaming movies or images) would my choice of io scheduler be very important? Regards, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: io scheduler silly question perhaps..
Try benchmarking Anticipatory or Deadline against Noop, preferably with your actual workload. Noop is probably what you want, since there is not much use in avoiding large seeks. It could be though that request merging, which the non-noop schedulers all perform, willl cause Noop to lose. I haven't tried any I/O scheduler benchmarks with flash, but perhaps we need a simple merge only scheduler for this sort of thing. Let me know what the results are. NATE On 7/28/05, Dave Airlie [EMAIL PROTECTED] wrote: I have an embedded system which has two read-only flash devices (one a PIO ATA flash disk, and one MDMA capable flash) As I'm doing no writing in this system and most of my reads are sequential (streaming movies or images) would my choice of io scheduler be very important? Regards, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
