On 2014-01-23 18:49, Vyacheslav Dubeyko wrote: > > On Jan 21, 2014, at 4:59 PM, 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. >> > > What does it defend us from eating 100% of CPU? Nothing really, but I don't think it's a big problem, because there is no possibility that you have constant 100% CPU. For every segment the timestamp is updated, so it will be protected by the protection period for a while. But you could be right. Maybe it is better to use a smaller timout instead of no timeout. I think I will change that in the next version of my patch. >> 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 > > Why do you declare a new constant? What does it means value of 513? > What bad in EAGAIN? I just thought that it's not a good idea to use an error code, that really could be returned from some system call. 513 is just 512+1. I wanted to make sure, that my error code does not conflict with any other existing errors < 512. Come to think of it, maybe you are right. I don't think that any of the calls in nilfs_reclaim_segment would return EAGAIN. So we could use it theoretically. But if a real error occurred, that returned EAGAIN for some reason, we could end up with very undesirable results. br, Andreas Rohner -- 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
