Messages in this thread | | | Date | Mon, 06 Jul 2009 15:55:31 +0300 | From | Artem Bityutskiy <> | Subject | Re: [PATCH 02/10] writeback: switch to per-bdi threads for flushing data |
| |
Jens Axboe wrote: > +/* > + * kupdated() used to do this. We cannot do it from the bdi_forker_task() > + * or we risk deadlocking on ->s_umount. The longer term solution would be > + * to implement sync_supers_bdi() or similar and simply do it from the > + * bdi writeback tasks individually. > + */ > +static int bdi_sync_supers(void *unused) > +{ > + set_user_nice(current, 0); > + > + while (!kthread_should_stop()) { > + set_current_state(TASK_INTERRUPTIBLE); > + schedule(); > + > + /* > + * Do this periodically, like kupdated() did before. > + */ > + sync_supers(); > + } > + > + return 0;
ATM we have one timer for both data and super-block synchronization. With per-bdi write-back we have:
1. one timer for super blocks 2. many per-bdi timers for data (schedule_timeout() is essentially using timers).
This is not nice, because each timer is an additional source of power-savings killers. I mean, it is more power management (PM) friendly to have less timers and disturb CPU less, make CPU wake up from retention less frequently.
I do not challange the per-bdi idea at all, but is it possible to think about a more PM-friendly desing and have one source of periodic write-back, not many. I mean, could there be one timer which periodically syncs supers and wakes up the BDI write-back tasks?
I've just started looking at your work, so I do not have good overall picture of what's going on, so apologies in advance if I missed something.
-- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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/
| |