On Fri, Mar 24, 2006 at 01:42:17AM -0800, Matt Helsley ([email protected]) wrote:
> On Fri, 2006-03-24 at 11:11 +0300, Evgeniy Polyakov wrote:
> > On Thu, Mar 23, 2006 at 11:35:50PM -0800, Matt Helsley ([email protected]) wrote:
> > > I would argue preemption should be disabled around the if-block at the
> > > very least. Suppose your rate limit is 10k calls/sec and you have 4
> > > procs. Each proc has a sequence of three instructions:
> > >
> > > load fsevent_sum into register rx (rx <= 1000)
> > > rx++ (rx <= 1001)
> > > store contents of register rx in fsevent_sum (fsevent_sum <= 1001)
> > >
> > >
> > > Now consider the following sequence of steps:
> > >
> > > load fsevent_sum into rx (rx <= 1000)
> > > <preempted>
> > > <3 other processors each manage to increment the sum by 3333 bringing us
> > > to 9999>
> > > <resumed>
> > > rx++ (rx <= 1001)
> > > store contents of rx in fsevent_sum (fsevent_sum <= 1001)
> > >
> > > So every processor now thinks it won't exceed the rate limit by
> > > generating more events when in fact we've just exceeded the limit. So,
> > > unless my example is flawed, I think you need to disable preemption
> > > here.
> >
> > Doesn't it just exceed the limit by one event per cpu?
>
> The example exceeds it by one at the time of the final store. Thanks to
> the fact that the value is then 1001 it may shortly be exceeded by much
> more than 1.
+
+ if (jiffies - last <= fsevent_ratelimit) {
+ if (fsevent_sum > fsevent_burst_limit)
+ return -2;
+ fsevent_sum++;
Only process (and not process' syscall) can preempt us here,
so fsevent_sum can only exceed fsevent_burst_limit by one per process
(process can not preempt itself, so when it has finished syscall which
ends up in event generation, fsevent_sum will be increased).
+ } else {
+ last = jiffies;
+ fsevent_sum = 0;
+ }
Actually, since jiffies and atomic operations are already used, I do not
think addition of new atomic_inc_return or something similar will
even somehow change the picture.
> Cheers,
> -Matt Helsley
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
