DragonFly BSD
DragonFly submit List (threaded) for 2003-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: proc extension request: p_sched


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 27 Dec 2003 11:10:08 -0800 (PST)

:Hi !
:
:May I have this in the tree ?
:This way I can have my world and kernel always
:in sync while testing userland scheduler variations.
:The overhead shouldn't be much of a problem and the
:struct sched can always be extended without recompiling
:the world.
:
:The struct runq there is only used as pointer and
:declared in my scheduler extension - which freezes
:my machine occassionly *sigh*...
:If anyone of you kernel-insiders would like to comment
:on my current code, I'd happily submit it of course.
:
:Thanks and
:Cheers
:Peter
:
:-- 
:<peter.kadau@xxxxxxxxxxxxxxxx>

    I will commit the pointer to sys/proc.h so your proc
    size doesn't change.  You'll have to maintain the
    rest of the stuff as a patch set for now... it looks
    like the structural topology needs some work so I'd rather
    not commit it all now.  For example, it is more likely that
    either p_sched would not be allocated and freed, or
    there would be two pointers hanging off the proc...
    one describing the scheduler and another describing
    per-process extension info.  I would prefer that no
    dynamic allocations be necessary for the default 
    scheduler but I can see their use for module-loaded
    schedulers... perhaps a union is a good compromise:

    struct proc {
	...
	struct scheduler *p_scheduler;	/* (static) describe scheduler */
	union sched	     p_sched; 		/* per-process scheduler info */
    }

    Then union sched would be:

    union sched {
	void	*s_ext;
	struct fubar_sched *s_fubar;
	struct {
	     ... embedded elements ...
	} bat_sched;
	struct {
	     ... embedded elements ...
	} bar_sched;
    }

    That is, it could accomodate both built-in non-dynamic schedulers
    and KLD schedulers, which would give us the flexibility of coming to
    a final decision later on down the line without sacrificing flexibility
    now.

    In anycase, for now I will commit the 'struct sched *p_sched' addition
    to struct proc to make your development work easier.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:+	u_int32_t sched_flags;
:+};
:+
: struct jail;
: 
: struct	proc {
:@@ -232,6 +239,7 @@
: 	void	*p_emuldata;	/* process-specific emulator state data */
: 	struct thread *p_thread; /* temporarily embed thread struct in proc */
: 	struct upcall *p_upcall; /* USERLAND POINTER! registered upcall */
:+	struct sched *p_sched;	/* user scheduler info */
: };
: 
: #if defined(_KERNEL)
:
:--------------060102090005000908090407--
:




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