Linux NILFS development
 help / color / mirror / Atom feed
From: Ryusuke Konishi <konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
To: dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Applying nice/ionice to nilfs-cleanerd
Date: Mon, 08 Aug 2011 20:59:32 +0900 (JST)	[thread overview]
Message-ID: <20110808.205932.260179154.ryusuke@osrg.net> (raw)
In-Reply-To: <201108081227.54922.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Mon, 8 Aug 2011 12:27:54 +0200, dexen deVries wrote:
> On Monday 08 of August 2011 12:20:14 you wrote:
> > And, we already have min_clean_segments threashold.  Why not just add
> > mc_nice and mc_ionice as below (rather than introduce the new
> > threthold) ?
> > 
> >  # Sheduing priority
> >  # if clean segments < min_clean_segments.
> >  mc_nice				-5
> > 
> >  # IO sheduing class and priority
> >  # if clean segments < min_clean_segments.
> >  mc_ionice			realtime
> 
> switching to faster free-space reclaimation already increases load on the 
> computer. If this also switched cleanerd to higher priority at the same 
> moment, the load increase could be sharp and unpleaseant. The idea was to have 
> three levels of cleanerd operation, rather than two.
> 
> 1) slow operation
> 2) fast operation -- when less than min_clean_segments is available
> 3) fast & aggressive (high nice and ionice priority) -- when there's even less 
> free space available
> 
> ...with the hope that the 3rd level would rarely ever be reached, because the 
>
> 2nd level would suffice most of the time.

Maybe, we should reorganize config parameters when using three or more
operation levels.  I feel we are reaching the breaking point from the
standpoint of both readability of the conffile and complexity of the
implementation.

I'm thinking about the following structural description (or git config
format and so on) for v2.2.

But, for the meantime, I'd like to add mc_nice and mc_ionice to avoid
the starvation issue simply.


mode default {
    device                 *   # target device (implicit)
    cleaning_interval      5
    nsegments_per_clean    2
    nice                   0
    ionice                 idle
}

mode low_capacity {
    start                  free_space < 10%
    exit                   free_space >= 20%
    cleaning_interval      1
    nsegments_per_clean    4
}

mode emerg {
    start                  free_space < 8%
    exit                   free_space >= 12%
    nice                   -5
    ionice                 realtime
}

Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      parent reply	other threads:[~2011-08-08 11:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-07 19:09 Applying nice/ionice to nilfs-cleanerd Gordan Bobic
     [not found] ` <28d103cbef1f8ebb3a7b458509e53c4d-tp2ajI7sM87MEvS+BUbURm2TqnkC6wfpXqFh9Ls21Oc@public.gmane.org>
2011-08-07 23:23   ` Ryusuke Konishi
     [not found]     ` <20110808.082319.114757823.ryusuke-sG5X7nlA6pw@public.gmane.org>
2011-08-07 23:34       ` Gordan Bobic
     [not found]         ` <4E3F211E.4060806-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>
2011-08-08  9:02           ` Ryusuke Konishi
2011-08-08  8:09       ` dexen deVries
     [not found]         ` <201108081009.31334.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-08-08  9:16           ` Gordan Bobic
2011-08-08 10:20           ` Ryusuke Konishi
     [not found]             ` <20110808.192014.264198882.ryusuke-sG5X7nlA6pw@public.gmane.org>
2011-08-08 10:27               ` dexen deVries
     [not found]                 ` <201108081227.54922.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-08-08 11:59                   ` Ryusuke Konishi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110808.205932.260179154.ryusuke@osrg.net \
    --to=konishi.ryusuke-zyj7fxus5i5l9jvzuh4aog@public.gmane.org \
    --cc=dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox