lkml.org 
[lkml]   [2003]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.0-test8/test9 io scheduler needs tuning?
As you rightly guessed, I was forgetting there are now 1000 jiffies per
second.

With your patch applied, I can achieve something close to 2.4
performance, but only if I set the limit on the number of pages to
submit at one time quite high. If I set it to 3000, I can get 20107 4K
pages written in 5267 jiffies (14MB/s) and can read them back at resume
time (so cache is not a factor) in 4620 jiffies (16MB/s). In 2.4, I
normally set the limit on async commits to 100, and achieve the same
performance. 100 here makes it very jerky and much slower.

Could there be some timeout value on BIOs that I might be able to
tweak/disable during suspend?

Regards,

Nigel

On Tue, 2003-10-28 at 14:37, Nigel Cunningham wrote:
> I'll try it with my software suspend patch. Under 2.4, I get around 45
> pages per jiffy written when suspending. Under 2.6, I'm currently
> getting 2-4, so any improvement should be obvious!
>
> Regards,
>
> Nigel
>
> On Tue, 2003-10-28 at 12:50, Nick Piggin wrote:
> > cliff white wrote:
> >
> > >On Tue, 28 Oct 2003 05:52:45 +0800
> > >Michael Frank <mhf@linuxmail.org> wrote:
> > >
> > >
> > >>To my surprise 2.6 - which used to do better then 2.4 - does no longer
> > >>handle these test that well.
> > >>
> > >>Generally, IDE IO throughput is _very_ uneven and IO _stops_ at times with the
> > >>system cpu load very high (and the disk LED off).
> > >>
> > >>IMHO the CPU scheduling is OK but the IO scheduling acts up here.
> > >>
> > >>The test system is a 2.4GHz P4 with 512M RAM and a 55MB/s udma IDE harddisk.
> > >>
> > >>The tests load the system to loadavg > 30. IO should be about 20MB/s on avg.
> > >>
> > >>Enclosed are vmstat -1 logs for 2.6-test9-Vanilla, followed by 2.6-test8-Vanilla
> > >>(-mm1 behaves similar), 2.4.22-Vanilla and 2.4.21+swsusp all compiled wo preempt.
> > >>
> > >>IO on 2.6 stops now for seconds at a time. -test8 is worse than -test9
> > >>
> > >
> > >We see the same delta at OSDL. Try repeating your tests with 'elevator=deadline'
> > >to confirm.
> > >For example, on the 8-cpu platform:
> > >STP id Kernel Name MaxJPM Change Options
> > >281669 linux-2.6.0-test8 7014.42 0.0
> > >281671 linux-2.6.0-test8 8294.94 +18.26% elevator=deadline
> > >
> > >The -mm kernels don't show this big delta. We also do not see this delta on
> > >smaller machines
> > >
> >
> > I'm working with Randy to fix this. Attached is what I have so far. See how
> > you go with it.
> >
> >
> > ______________________________________________________________________
> >
> > linux-2.6-npiggin/drivers/block/as-iosched.c | 30 ++++++---------------------
> > 1 files changed, 7 insertions(+), 23 deletions(-)
> >
> > diff -puN drivers/block/as-iosched.c~as-fix drivers/block/as-iosched.c
> > --- linux-2.6/drivers/block/as-iosched.c~as-fix 2003-10-27 14:53:47.000000000 +1100
> > +++ linux-2.6-npiggin/drivers/block/as-iosched.c 2003-10-27 14:54:04.000000000 +1100
> > @@ -99,7 +99,6 @@ struct as_data {
> > sector_t last_sector[2]; /* last REQ_SYNC & REQ_ASYNC sectors */
> > struct list_head *dispatch; /* driver dispatch queue */
> > struct list_head *hash; /* request hash */
> > - unsigned long new_success; /* anticipation success on new proc */
> > unsigned long current_batch_expires;
> > unsigned long last_check_fifo[2];
> > int changed_batch; /* 1: waiting for old batch to end */
> > @@ -585,18 +584,11 @@ static void as_antic_stop(struct as_data
> > int status = ad->antic_status;
> >
> > if (status == ANTIC_WAIT_REQ || status == ANTIC_WAIT_NEXT) {
> > - struct as_io_context *aic;
> > -
> > if (status == ANTIC_WAIT_NEXT)
> > del_timer(&ad->antic_timer);
> > ad->antic_status = ANTIC_FINISHED;
> > /* see as_work_handler */
> > kblockd_schedule_work(&ad->antic_work);
> > -
> > - aic = ad->io_context->aic;
> > - if (aic->seek_samples == 0)
> > - /* new process */
> > - ad->new_success = (ad->new_success * 3) / 4 + 256;
> > }
> > }
> >
> > @@ -612,14 +604,8 @@ static void as_antic_timeout(unsigned lo
> > spin_lock_irqsave(q->queue_lock, flags);
> > if (ad->antic_status == ANTIC_WAIT_REQ
> > || ad->antic_status == ANTIC_WAIT_NEXT) {
> > - struct as_io_context *aic;
> > ad->antic_status = ANTIC_FINISHED;
> > kblockd_schedule_work(&ad->antic_work);
> > -
> > - aic = ad->io_context->aic;
> > - if (aic->seek_samples == 0)
> > - /* new process */
> > - ad->new_success = (ad->new_success * 3) / 4;
> > }
> > spin_unlock_irqrestore(q->queue_lock, flags);
> > }
> > @@ -708,11 +694,10 @@ static int as_can_break_anticipation(str
> > return 1;
> > }
> >
> > - if (ad->new_success < 256 &&
> > - (aic->seek_samples == 0 || aic->ttime_samples == 0)) {
> > + if (aic->seek_samples == 0 || aic->ttime_samples == 0) {
> > /*
> > - * Process has just started IO and we have a bad history of
> > - * success anticipating on new processes!
> > + * Process has just started IO. Don't anticipate.
> > + * TODO! Must fix this up.
> > */
> > return 1;
> > }
> > @@ -1292,7 +1277,7 @@ fifo_expired:
> >
> > ad->changed_batch = 0;
> >
> > - arq->request->flags |= REQ_SOFTBARRIER;
> > +// arq->request->flags |= REQ_SOFTBARRIER;
> > }
> >
> > /*
> > @@ -1391,6 +1376,7 @@ static void as_add_request(struct as_dat
> >
> > } else {
> > as_add_aliased_request(ad, arq, alias);
> > +
> > /*
> > * have we been anticipating this request?
> > * or does it come from the same process as the one we are
> > @@ -1427,8 +1413,6 @@ static void as_requeue_request(request_q
> >
> > /* Stop anticipating - let this request get through */
> > as_antic_stop(ad);
> > -
> > - return;
> > }
> >
> > static void
> > @@ -1437,10 +1421,12 @@ as_insert_request(request_queue_t *q, st
> > struct as_data *ad = q->elevator.elevator_data;
> > struct as_rq *arq = RQ_DATA(rq);
> >
> > +#if 0
> > /* barriers must flush the reorder queue */
> > if (unlikely(rq->flags & (REQ_SOFTBARRIER | REQ_HARDBARRIER)
> > && where == ELEVATOR_INSERT_SORT))
> > where = ELEVATOR_INSERT_BACK;
> > +#endif
> >
> > switch (where) {
> > case ELEVATOR_INSERT_BACK:
> > @@ -1823,8 +1809,6 @@ static int as_init(request_queue_t *q, e
> > if (ad->write_batch_count < 2)
> > ad->write_batch_count = 2;
> >
> > - ad->new_success = 512;
> > -
> > return 0;
> > }
> >
> >
> > _
--
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.670 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site