On Sun, May 10, 2009 at 12:47:26PM -0700, Eric Day wrote:
> The drizzled process (scheduler plugin) would be the one doing the
> context switching. This would make it more efficient because drizzled
> has better context of when to switch, and you don't have the jump to
> kernel space. There are obviously some drawbacks here, and the issue
> of how portable this will be, but Stewart thinks it will be doable.
>
> Stewart, want to add anything? :)
Sure, make me think :)
If you look at the getcontext/setcontext man page:
> In a System V-like environment, one has the two types mcontext_t and
> ucontext_t defined in <ucontext.h> and the four functions getcontext(),
> setcontext(), makecontext(3) and swapcontext(3) that allow user-level
> context switching between multiple threads of control within a process.
Which lets you implement co-operative threading in user space.
The idea behind doing this is:
- with many connections (1,000+):
- the overhead of the OS context switching gets non-trivial
- the context switches happen at non-optimal points. i.e. we could
get better throughput/response time if we only switched at logical
points such as on blocking IO, mutex contention etc.
- The OS doesn't have enough knowledge to do some things (e.g.
there is likely no point in context switching during parsing... it's
just going to thrash the cache and make perf suck)
- with huge numbers (10,000):
- ever try having another process get any CPU time with 10,000
database threads running? It would be nice to still be able to SSH into
the box or to have the "help, i'm overloaded" monitoring process get
enough CPU time to report that.
- there are some things we can only do with real knowledge of what's
going on
- we could work out how long it may take to get to processing an
incoming connection and return EBUSY - better handling situations where
we're severely overloaded by continuing to service all we can and
providing useful error messages back to users.
- kind of interesting micro-optimisations
- task_struct in linux is close to 2kb. for 10,000 connections,
this means we're using 20MB of memory just for the task_struct -
ignoring all the other bits of memory hanging around in kernel (e.g. the
stack for that task). If you count the 4kb stack, we're looking at over
60MB of memory just for kernel structures tracking 10,000 database
connections.
- we should be able to get away with a bit less
considering that struct ucontext is only:
struct ucontext {
unsigned long uc_flags;
struct ucontext *uc_link;
stack_t uc_stack;
struct sigcontext uc_mcontext;
sigset_t uc_sigmask;
};
- pid_t deafults to max out at 32,768.... would be nice not to
hit it.
--
Stewart Smith
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
