On Mon, Jul 26, 2010 at 09:04:17PM +0200, Tejun Heo wrote:
> On 07/26/2010 06:23 PM, Michael S. Tsirkin wrote:
> >> * Can you please keep the outer goto repeat loop? I just don't like
> >> outermost for (;;).
> >
> > Okay ... can we put the code in a {} scope to make it clear
> > where does the loop starts and ends?
>
> If we're gonna do that, it would be better to put it inside a loop
> construct. The reason why I don't like it is that loops like that
> don't really help read/writeability much while indenting the whole
> logic unnecessarily and look more like a result of obsession against
> goto rather than any practical reason. It's just a cosmetic
> preference and I might as well be the weirdo here, so if you feel
> strong about it, please feel free to put everything in a loop.
>
> >> * Placing try_to_freeze() could be a bit annoying. It shouldn't be
> >> executed when there's a work to flush.
> >
> > It currently seems to be executed when there is work to flush.
> > Is this wrong?
>
> Oh, does it? As I wrote in the other mail, things like that wouldn't
> necessarily break correctness but I think it would be better to avoid
> surprises in the generic code if not too difficult.
Let's try to define what do we want to achieve then.
Do you want code that flushes workers not to block
when workers are frozen? How will we handle work
submitted when worker is frozen?
> >> * I think A - B <= 0 test would be more familiar. At least
> >> time_before/after() are implemented that way.
> >
> > I am concerned that this overflows a signed integer -
> > which I seem to remeber that C99 disallows.
>
> Really? Overflows of pointer isn't expected and that's why we have
> weird RELOC_HIDE() macro for such calculations but integers not
> expected to overflow is a news to me. Are you sure? That basically
> means time_before/after() aren't safe either.
As I said, in C99.
However, the kernel is built with -fno-strict-overflow, so it will work.
> > timer macros are on data path so might be worth the risk there,
> > but flush is slow path so better be safe?
>
> I don't think performance matters much here. I just think the sign
> test is clearer / more familiar for the logic.
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
