From: Simon Horman <horms@verge.net.au>
To: Graeme Fowler <graeme@graemef.net>
Cc: Jason Stubbs <j.stubbs@linkthink.co.jp>, lvs-devel@vger.kernel.org
Subject: Re: Least Connection Scheduler
Date: Wed, 2 Apr 2008 17:31:21 +0900 [thread overview]
Message-ID: <20080402083119.GA14708@verge.net.au> (raw)
In-Reply-To: <1207124157.16121.4.camel@ernie.internal.graemef.net>
On Wed, Apr 02, 2008 at 09:15:57AM +0100, Graeme Fowler wrote:
> On Wed, 2008-04-02 at 17:04 +0900, Simon Horman wrote:
> > LVS does already have a number of /proc values that can be twiddled
> > so I personally don't see a problem with adding one more - then again
> > I'm bound to say that as it was my idea.
>
> Personally speaking, the more stuff that's controllable with /proc the
> better - it makes it easier to code up additional control environments
> without the execution overhead of calling ipvsadm multiple times.
>
> > If you want to code it up as an additional scheduler that is fine.
> > But looking at your numbers, I am kind of leaning towards just
> > using your existing patch.
>
> Pardon me for speaking out of turn, but an idea just crossed my mind -
> wouldn't it be better to "merge" (not in code terms) the lc and wlc
> schedulers so they either base on, or use exactly, the same code? After
> all, in concept the lc scheduler is simply wlc with equal weights of 1.
> Isn't it?
> That shrinks the codebase a bit.
Yes, I think that would be an excellent idea.
We could still have the different schedulers (for compatibility), but
have them share common code - which would basically be all of it.
I imagine that the same thing could be done for rr and wrr.
I guess that the original motivation for the separation was
either performance or to demonstrate it was possible to have more
than one scheduler at a time when there was only one.
> > I agree that the only real problem would be the extra number of
> > inactive connections on the faster server. But the overhead of such
> > things is really quite small - ~128 bytes of memory and a bit of
> > extra time to go through the hash table (maybe).
>
> This would only be a problem in really large throughput situations, and
> if you have one of them you probably already have some $$$ to buy a
> faster processor!
Yes, I was struggling to think of a situation where it would be
a problem in practice.
--
Horms
next prev parent reply other threads:[~2008-04-02 8:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-01 4:36 Least Connection Scheduler Jason Stubbs
2008-04-01 5:16 ` Simon Horman
2008-04-01 5:55 ` Jason Stubbs
2008-04-02 2:38 ` Jason Stubbs
2008-04-02 8:04 ` Simon Horman
2008-04-02 8:15 ` Graeme Fowler
2008-04-02 8:31 ` Simon Horman [this message]
2008-04-03 11:14 ` Jason Stubbs
2008-04-03 0:58 ` Jason Stubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080402083119.GA14708@verge.net.au \
--to=horms@verge.net.au \
--cc=graeme@graemef.net \
--cc=j.stubbs@linkthink.co.jp \
--cc=lvs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.