Re: RFC: continous counters (fwd)

Hi Krzysztof,

On Mon, Nov 05, 2007 at 07:53:46PM +0100, Krzysztof Oledzki wrote:
> >>This is somehow different from what I observed: with first call "flags &
> >>BE_ASSIGNED" indeed returns 0, but at the same time s->req->total is
> >>still 0. If I understand it right it gets incremented only after a request
> >>get delivered to a server.
> >
> >Oh, that's possible. I'll have to check too.
>
> Please do. I might have overlooked something.

I'll try to take some time today for this and will get back to you ASAP.

> >>So, changing:
> >> if (s->fe->options & PR_O_CONTCNT)
> >>into:
> >> if ((s->fe->options & PR_O_CONTSTATS) && (s->flags & SN_BE_ASSIGNED))
> >>does not change anything from counter's point of view, hovewer it prevents
> >>this empty call so I trust you that this is better.
> >
> >If what you say is true, the second check can be removed, however adding
> >a comment above it justifying why it cannot cause trouble is important.
>
> Since this does not cost too much I think it may be safe to keep it. If
> anything changes it will not break it. What do you think?

"better safe than sorry" => if we find that it's complicated to find out whether the check is needed or not, let's keep it.

> >I have tried your patch. Oddly, it was mangled again and did not apply.
> >But differently this time : the unchanged lines, which began with a
> >space had their space doubled. This may be because of the encoding, I
> >don't know. I think the most reliable solution is to attach them, even
> >if that makes it harder for inlined comments. We'll see in the long term
> >what is preferable.
>
> I am starting to hate this "pine". :( It was the last patch mailed with
> this client, I promise. ;)

I had someone else who once had such problems with pine, but many people on LKML (including Linus) use it without problems. I suspect that there are non-obvious config options to adjust it. Maybe you can find some info about this on the net. Or you can ask on LKML, it's not completely off-topic overthere.

> >Anyway, I fixed it using sed and tested it. The performance impact when
> >the option is disabled is not measurable (that's good). When it is
> >enabled, it only has a very small impact (I measured about 0.5%), which
> >means that people who use scripts to generate configurations will be
> >able to enable it by default without a big trade-off.
> >
> >Would you please rediff it against -master, so that I apply it there ?
>
> Of course. I also going to add some short doc about this feature.

OK fine!

I think that 1.3.14 will take some time, because I have quite a number of changes to perform before releasing it, si I'll do my best to regularly push changes to git. If other persons on the list would like to get some snapshots sometimes, I can produce some once in a while.

Cheers,
Willy Received on 2007/11/08 06:26