On Sun, 2014-01-19 at 15:01 +0100, Andreas Rohner wrote: > This patch adds the custom error value EGCTRYAGAIN, which signals to > cleanerd to retry the gc process as soon as possible with no timeout. > > If the GC decides not to do any real work and only changes a few > metadata bytes, there is no need for a timeout. Furthermore if the GC is > running, there is probably not enough free space on the device and it is > crucial to retry quickly. Now GC really decrease performance very frequently. So, you suggest don't use timeout. :) I am afraid that it can decrease performance more. Why do you think in opposite manner? If we doesn't relate with idle system state or I/O load then rigid timeout can really decrease performance, as far as I can judge. The main problem of GC that it works in the background of main file system operations and, as a result, decrease the whole performance. So, how the "no-timeout" does correlate with main file system operation or with the whole system load? Could you describe your vision how it will work? I think that it makes sense to have in this patch as declarations as implementation of concept. Otherwise, it is hard to understand the goal of such suggestion. > > Signed-off-by: Andreas Rohner <andreas.rohner@xxxxxxx> > --- > include/nilfs_gc.h | 2 ++ > sbin/cleanerd/cleanerd.c | 10 +++++++++- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/include/nilfs_gc.h b/include/nilfs_gc.h > index 72e9947..7628ce1 100644 > --- a/include/nilfs_gc.h > +++ b/include/nilfs_gc.h > @@ -27,4 +27,6 @@ static inline int nilfs_suinfo_reclaimable(const struct nilfs_suinfo *si) > > extern void (*nilfs_gc_logger)(int priority, const char *fmt, ...); > > +#define EGCTRYAGAIN 513 Is it really need to add special constant? Why don't use EAGAIN? Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
