Neale,
I may be wrong, but it looks like you may have gotten confused by
parallel code-paths. cpu_disqalloc() is called by disp_setup().
disp_setup() is only called by dispinit(), at platform initialization
time, and by disp_add(), when you add a new scheduler class.
The code that allocates a dis
> >Perhaps. So one detail that may be important here, is the balancing
> >is performed between the per priority queues, not the CPUs total run
> >queue. The idea is that if you have some threads at priority 0, some
> >at priority 10, and some at 20, that you'll have a fairly even
> >distribution of
> I was thinking about the traditional Unix view of a "swap slice", e.g. a
> settop-box may only have flash memory and no swap disk/slice etc.
I think that in this case, as long as you don't configure the flash disk
to be part of a swap partition, the kernel will reserve physical memory
as swap in
> Would it be usefull to create a kernel flag to mark all process stack
> memory with |MAP_NORESERVE|, e.g. don't allocate swap memory for stacks
> ? The idea is to reduce the swap requirements for platforms like settop
> boxes etc. with limited or no swap space by exploiting the detail that
> almo
> I'm not asking for standards to be compromised or for special
> treatment - I'm asking for every ON SME (Subject Matter Expert) to
> ease the learning curve and pain and lower the barriers that any
> external contributor will be faced with while trying to integrate,
> successfully, into ON.
> But if Meem can checkout the file and make the changes in less time
> than it takes him to write the review comment - does it make sense for
> him (and every other reviewer) to write a seemingly endless set of
> change requests?
This actually isn't the role of the code reviewer.
I'm my exp
Al,
> The project team chose to go into ON rather than some other more
> suitable consolidation such as SFW. ON's bar is intentionally set
> very high -- these are the crown jewels we're talking about here. I
> doubt you're going to get much agreement that the bar on entry to ON
> should be lowe
> > What about using shell scripts instead of perl? Oh, wait... I
> > forgot... Solaris doesn't use ksh93 as /bin/sh. What a pity :-(
This comment is a non sequitur. sh is the name of the Bourne Shell,
ksh93 is the name of Korn Shell '93. /bin/sh isn't ksh93 because it is
a distinct shell with i
Garrett:
> But one should not, I think, ignore the overhead that adding new
> runtimes (and even new compile-time languages) adds. Each language
> needs (typically) either or both of a full time runtime environment and
> a development tool chain.
I'm not suggesting that we ignore the overhead.
> It's a *review* committee -- that's what the "R" in ARC stands for.
> We review the things that others propose.
Okay, but I'm still at a loss. If you find the description "committee
decision" to be pejorative and offensive, please suggest an alternative.
> Suggesting that PSARC would fly off t
> [F]or the same reason [a Perl developer] may need to consider (for
> example) the restrictions that Zones place on packaging, and how that
> affects his project, he may well have to wander outside the narrow
> confines of his project to do that.
I agree.
> I'm suggesting that interested parties
> Another perfectly valid way to look at this is that Perl is _forced_
> to be part of the minimum install image _because_ it's used for
> important system components.
>
> That's still architectural.
There is a distinction between the runtime environment and the code the
developer writes and main
> >Is there an API which can be used to limit the number of threads/LWPs
> >per process/process group (e.g. similar to "ulimit" (e.g. not
> >per-project)) ? Some platforms define |RLIMIT_PTHREAD| for this purpose
> >but I can't find something similar for Solaris (it would be usefull to
> >get ksh93
> Question #1
> I was looking at the code of resume() at swtch.s. The %g7 resister
> seems to hold a pointer to the thread structure. Is that pointer to
> the user-level one or the kernel-level one?
In the kernel, the %g7 register contains the address of the kthread_t
structure that is the thread
14 matches
Mail list logo
