On Wednesday 29 April 2009 14:50, Andi Kleen wrote:
> Krzysztof Bâaszkowski <kb@xxxxxxxxxxxxxxx> writes:
> > Hello,
> >
> > once upon i was asked to think about such facility for notifying
> > userspace when some mount point is nearly full at some level let's say
> > e.g. 90% (threshold should be configurable).
> >
> > here is a solution designed by me and i would like to see comments on
> > this idea and solution.
>
> It doesn't seem to be very useful to poll in kernel for this. When you're
> in kernel you could just hook into the respective functions that handle
> disk allocation directly.
i reckon yes and no both. "no" because i wanted a solution which will have
almost no impact on performance. if the speed wasn't an important concern
then why would one take care about per cpu counters like fdblocks ?
> Polling can be as well done in user space only,
> so it doesn't make too much sense to put polling code into the kernel.
yes i think too, that's maybe a bit too huge thing looking at benefits it
brings but consider bash instance consuming 1.5M (at least) and other things
spawned periodically,
do they have more sense ? i don't think so and this is the solution which
voids all hassle with userspace polling because it uses unified notification
system and this can be good starting point for notification system for other
purposes i haven't think of yet but maybe someone has a new idea regarding
this.
are these reasons good to (complete and) merge this stuff ?
I found that the xfs-sysfs-2 requires small rework around event_alloc() and
event_release() because of very rare (but possible) race with timer function
which drops lock (i decided to drop lock because i think kobject_uevent may
be synchronous in the case of deprecated /sbin/hotplug and i'm not sure also
how long it takes for udevd)
i think that there is no point to update patch as long as we will not sort out
if the whole idea is really worth to implement.
Thanks for reply.
Krzysztof Blaszkowski
>
> -Andi
|