DragonFly BSD
DragonFly commits List (threaded) for 2006-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/conf files src/sys/ddb db_ps.c src/sys/i386/i386 trap.c src/sys/kern init_main.c kern_synch.c kern_usched.c lwkt_thread.c usched_bsd4.c usched_dummy.c src/sys/sys globaldata.h thread.h usched.h


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 29 May 2006 16:35:15 -0700 (PDT)

:While I am here, can the schedulers allow userspace to specify a cpumask
:a thread is willing to run on, some highend software e.g database
:systems may want this feature, as they are intend to manager their
:CPU locality like they did for RAW device.
:

    This would be a good mini-project.  I think it would be quit easy
    to add this level of control.  The current BSD4 scheduler implementation
    uses cpu masks as part of its core algorithm.

    If someone would like to take on this project I recommend tying the
    feature into usched_set().  Maybe change it from:

	int usched_set(const char *name, int flags);

    To something more generic:

	int usched_set(pid_t pid, int cmd, void *data, int bytes)

	USCHED_SET_SCHEDULER

		Set the scheduler for the specified process based on the
		passed string.  data should be a string pointer and bytes
		should be the length of the string not-including the
		zero terminator.

		Currently only "bsd4" is supported.

	USCHED_ADD_CPU

		Add the cpu id pointed to by the data to the set of
		cpu's that the process is allowed to run on.  e.g.:

			int cpu = blah;
			usched_set(getpid(), &cpu, sizeof(cpu));

	USCHED_DEL_CPU

		Remove the cpu id from the set of cpus the process is
		allowed to run on.

		This command will fail if the removal of the cpu id would
		result in the process not being able to run on any cpus.

	USCHED_SET_CPU

		Make the specified cpuid the only cpu that the process is
		allowed to run on. 


    I think it would be a very easy project for someone to clean up
    usched_set() and then add the cpu masking features.  For an initial
    implementation the 'pid' would have to be restricted to just the calling
    process's pid (else it gets quite messy).  But all children would inherit
    the scheduler setup so it would be easy to test.

    If someone does the work to get it to that point I can sit down and
    do the rest... allowing foreign pids, and doing the nitpicky stuff
    in usched_bsd4.c to actually make cpu masking work.  All I am asking
    for is that someone build the framework leading up to that point.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]