|
Roberto Nibali <ratz@xxxxxxxxxxxx> wrote:
>>> The current implementation of my original 2.2.x patch in the 2.6.x
>>> kernel is in my view unfinished and can hardly be used in production for
>>> sites with heaps of page views and business logics in application servers.
>>>
>>> Threshold limitation patch and user space patch follow.
>>>
>>> Please discuss,
>>
>> Conceptually it seems like a reasonable idea, though if
>> you have per-real server thresholds is it really needed?
>
> No and yes. The hprio scheduler is not needed anymore for the spillover
> (or session overflow) pool implementation, since the switch from native
> RS to spillover happens atomically in the kernel. Since I did not have
> this code until 2 weeks ago, the hprio scheduler kind of replaced that
> functionality, at least using a RR scheduler.
>
> It could be needed though if you want stacked addition of RS to handle
> spike loads for you system. So long as everything is working normally
> the spare servers can be used for other things.
Right, so its probably as well for it to just sit in the
mailing list archive for now. If it proves to be a useful idea
it can get honned at athat time.
I'm pretty convicned that your spillover/thresholds patch
so lets ride with that for now.
>> In terms of code, it looks good, though traversing the
>> real-serves in ip_vs_hprio_max_weight() and again in
>> ip_vs_hprio_schedule() seems like it could be merged
>> into a single loop. But thats not a big deal.
>
> Indeed it could. Even better would be to put the max_weight into
> ip_vs_ctl.c where the interaction with user space is happening since
> it's the only place where weights get changed and max weight is a pretty
> static thing.
True, I thought of that and dimissed it as overhead. But
now you mentinon it again, its probably the best place for it
by far. That said, I don't think there are any consumers for
it (appart from hprio) right now.
>> I'm not sure if its really material to to go upstream.
>
> That's ok. So long as the rest can be merged, once I get the 2.6 port
> ready.
Yeah, thats about what I was thinking.
>> If you think it is, then a 2.6 version will be the way to
>> go as I believe 2.4 is only accepting bug fixes now.
>
> Unfortunately yes. I'll certainly cook up a 2.6 version of my patch.
> This will also allow me to get a broader test base and acceptance by the
> users.
Again, pretty much what I was thinking.
You could always try and squeeze it past Marcello,
but if I were in his shoes I would probably knock it back.
Btw, thanks for your lightening fast response,
in contrast to my ~ one month delay.
--
Horms
|
