Re: [osol-code] Context switch and %g7 register
> 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 running on the current CPU. This is the value of CPU->cpu_thread. > I have this question because of my following confussion; if %g7 holds > a pointer to the kernel thread then somehow it needs to be not > available to user-mode since this will violate process/kernel > boundaries. On the other hand if it points to user-level structure, > then it is not reasonable since that structure could be modified by > user-mode. Clearly I am missing something here. I know that in SPARC > there is this alternate global set. Does the kernel use that alternate > global? Or does the kernel clear the %g7 register before getting to > user mode? If this is the case, could someone point me to the place > where this happen? The %g7 register is setup by the trap code. On sun4u, user_trap() determines the CPU->cpu_thread, stashes it in %l6 and calls utl0(). The code in utl0() moves %l6 to THREAD_REG which is defined as %g7. In the syscall case, the utl0() code then invokes the sycall_trap handler. utl0, unless I'm mistaken, vectors to the TL0 trap table. Outbound, the proces is reversed in user_rtt(). Parenthetically, the SysV ABI for SPARC lists the %g registers as reserved for system software. code which is ABI compliant shouldn't be setting the %g7 register. However, the kernel obviously doesn't trust the value of %g7 from userland and, as mentioned above, generates the correct value when a trap is taken. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] Limiting the number of threads/LWPs per process/process group...
> >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's ulimit "-T" option implemented) ... ;-( > > It's a resource control in Solaris. Perhaps I'm missing something obvious; however, a cursory rctl exam seems to indicate that this functionality is only implemented on a per task/project/zone basis: $ rctladm -l | grep lwp task.max-lwps syslog=off [ count ] project.max-lwpssyslog=off [ no-basic count ] zone.max-lwps syslog=off [ no-basic count ] -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: perl in Solaris (was Re: [osol-code] Re: disable processor(s))
> 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 maintains. As Darren has pointed out twice, the Perl runtime is already part of ON. Why should a Perl developer have to concern him/herself with architectural issues about the runtime? In the general case, I don't have to worry about architectural issues with ld.so.1(1) just because I've written a dynamically linked executable. > > Now adding Python or other language runtime of choice into the minimal > > install image would be architectural, but Perl is already there. > > Yes, those would have essentially the same sort of impact. As far as > I know, there's no explicit policy or precedent here. If we're trying to make it easier for more people to develop OpenSolaris, making rules about what languages can and can't be used seems counterproductive. I happen to agree with Darren on the point that PSARC isn't the place to make these decisions. Having a committe make a implementation decision for a developer really isn't appropriate. However, if you're intent upon having a PSARC precedent, I'll draft a case requiring all future development in OpenSolaris to take place in Z80 assembly and COBOL. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: perl in Solaris (was Re: [osol-code] Re: disable processor(s))
> [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 should draw up suitable > language for such a rule, and run it as an ARC case. PSARC would > probably be a reasonable place to have it reviewed, as it's a platform > issue. I'm not sure that I see a need for these kinds of rules. If PSARC wants to review the plans for adding new runtimes to OpenSoalris, that seems reasonable. However, to tell developers that they can't use a certain language for development work seems silly. > By casting this as a (presumably pejorative) "committee decision," My comment about Z80 and COBOL was intended to be snide; however, you shouldn't presume that my comment about, "Having a committee make an implementation decsion..." was pejorative. The "C" in ARC stands for Committee, does it not? How am I to describe the decision reached by a consenus of the committee members if not as a decision made by committee? > I think you're substantially misunderstanding how our development > system actually works and disparaging the work of those who > participate in the process. This kind of attack is inappropriate. I participate in this process and am not disparaging anybody's work. You don't have to agree with my opinion, but at least be respectful. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: perl in Solaris (was Re: [osol-code] Re: disable processor(s))
> 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 the rails and invent a ban on Perl > on behalf of all Open Solaris projects seems misguided to me, and it > certainly sows unwanted seeds of doubt about how the process works. I don't believe that was what I suggested. It seemed to me that you had suggested that a precedent be set for which languages it would be acceptable for developers to use. If that's not what was suggested then this is a misunderstanding. > Instead, I'm suggesting that I think Darren has it wrong. The use of > Perl (and the cost to the overall system it causes, and the > restrictions it imposes on other projects [such as minimization]) is > architectural in nature. Darren was suggesting that it was not > architectural because Perl is already in the minimum required > metacluster. My point is that this doesn't remove the question -- it > certainly changes the nature of it for other projects (without a > change in policy, and assuming project boundaries are maintained, > there's no real restriction on who may use it) -- but it doesn't make > the issue less architectural. Thanks for the clarification. This explanation seems clearer than previous descriptions. > > This kind of attack is inappropriate. I participate in this process and > > am not disparaging anybody's work. You don't have to agree with my > > opinion, but at least be respectful. > > That's exactly what I was asking. My comments were not intended to be taken as a personal attack. I apologize if they came across otherwise. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: perl in Solaris (was Re: [osol-code] Re: disable processor(s))
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. However, in your previous post you lamented the fact that Perl 5.8.x was now at 38mb. With 500gb disks showing up as standard in most systems, 38mb doesn't really seems that large any more. > And, I'm not suggesting that we should prohibit perl development. It sounds like I've misunderstood. It really sounded to me like what was said was, "No Perl code should be checked into ON again, and we should have a PSARC case to enforce this." I guess this wasn't what was actually meant. > Rather I've suggested that PSARC (or whatever other powers-that-be is > appropriate) should aim that installation of perl on Solaris should be > "optional". In other words, I think that software that is part of the > "minimal install" should not depend on other large external runtimes > (I'll go ahead and extend this to Java and ksh93 as well, if you prefer) > such as Perl. (Compile time toolchain requirements should be considered > by the various REs involved ... I don't care much about Compile time > requirements so much as the runtime overhead.) Isn't a "large" runtime a moving target? If we set a maximum size for inclusion in the default install today, isn't that going to be obsolete before 2012? I'd be in favor of using common sense in these situations instead of rules. That said, if we actually do have a minimization project in the works, I agree that it would be better for everyone involved if the dependancies for the "minimal install" were codified in an ARC case. Another alternative is to consider stripped down versions of important runtimes, although I'm not sure if that's germane to the current discussion. > Looking at the competitive landscape, I've built Linux and NetBSD > distributions that were functional and occupied less than 4 MB total. > While these were primitive builds, for single-function devices, I think > it is useful to think about space and bloat. It'd be nice if developers > would occasionally make an effort to develop software that make > assumptions about Moore's Law. :-) For a single-function, single CPU device, you probably don't need intrd anyway. :P Assumptions about Moore's Law have also changed over time. This is certainly unrelated to the current discussion but interesting none the less: http://firstmonday.org/issues/issue7_11/tuomi/index.html -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: perl in Solaris (was Re: [osol-code] Re: disable processor(s))
> > 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 it's own name, sh. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] Re: [Fwd: [ksh93-integration-discuss] ksh93-integration pre-reviewround"two" (webrev 2007-05-14)]
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 lowered to allow just "any" open source code. > > I think it's Roland's cross to bear that he chose ON and is sticking > with it. I agree with James. Many people suggested that Roland consider integrating KSH93 into the SFW consolidation. SFW is specifically geared towards handling open-source software not directly developed as part of OpenSolaris. SFW has different, and more relaxed, requirements for project integrations. It would have been a more suitable place for KSH93 and it would have taken less time to integrate there. Despite the advice offered to Roland, he chose to integrate KSH93 into ON. The standards for ON integrations should be the same, regardless of who is filing the RTI. Don't blame the KSH93 reviewers, who are also volunteers, for a choice that the KSH93 project team made. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] Re: [Fwd: [ksh93-integration-discuss] ksh93-integration pre-reviewround"two" (webrev 2007-05-14)]
> 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 experience, reviewers often bring up points that require further discussion or are negociable. As a developer, I would be frustrated if a reviewer made a change in code that I was working on without first discussing the matter in detail. I would rather make the change myself, instead of having a code reviewer do it for me. > I don't see the reviewer offering up his experience and suggesting > changes or even providing a "pointer" (aka URL) to a suitable > solution. IOW - for someone unfamiliar with the problem domain, it > might take them several hours to figure out the "problem" and devise > the "solution" - while the reviewer could resolve the issue, in a > fraction of that time. Maybe and maybe not. It's also entirely possible that the reviewer can point out something that could easily be fixed by the developer, whereas it would take the reviewer much longer to learn the new code and make the fix. Fundamentally, it's the job of the code reviewer to provide review and feedback. The developer is responsible for fixing the bugs and translating the feedback into something that satisfies the concerns raised in the review process. > Agreed - I'm just asking him to be part of the solution instead of > spending more than the equivalent time pointing out the need for > changes. Code review really is part of the solution. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] Re: [Fwd: [ksh93-integration-discuss] ksh93-integration pre-reviewround"two" (webrev 2007-05-14)]
> 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. I don't think that it is unreasonable to ask this. It might be better to ask questions like: - Where is the learning curve the steepest for new developers? - What parts of integration are most painful? - What barriers are contributors facing? I think that if we can come to some concensus about what the hurdles are, it's more likely that we'll be able to address them in some way that actually helps new developers. I think everyone subscribed to this list wants to see new OpenSolaris developers successfully integrate projects. I certainly do. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] Kernel flag to reduce swap usage of reserved (but unallocated) stack memory...
> 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 > almost all applications reserve memory for large stacks (8MB default) > but only use a tiny fraction (most shells and shell applications rarely > use more than 64k). When you say, "limited or no swap space," what are you really talking about here? Solaris can use both memory and disk as reserved memory swap. Check out anon_resvmem() in the kernel. It can take pages from either a swap device or memory. If you have a fininite amount of resource, using MAP_NORESERVE means that your failure mode for overuse will be non-deterministic. I.e. you'll get a SIGBUS or SIGSEGV when you try to write to the stack and a page cannot be allocated. I'm in favor of the more deterministic method of having the failure occur at allocation time because we're out of memory. (It's easier to debug too) -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] Kernel flag to reduce swap usage of reserved (but unallocated) stack memory...
> 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 instead. > > If you have a fininite amount of resource, using MAP_NORESERVE means > > that your failure mode for overuse will be non-deterministic. I.e. > > you'll get a SIGBUS or SIGSEGV when you try to write to the stack and a > > page cannot be allocated. > > ... my point is that if the machine only has 128MB and no swap (disk) is > available (e.g. LiveDVD) then every single wasted memory page is one too > much. I don't understand this reasoning. I agree that we don't want to waste memory in this situation. However, in the case of 128MB mem and no swap device, a call to anon_resvmem() will simply deduct the amount of memory that is available to the system by the size of the requested reservation. This is necessary because we've taken a pagefault in the stack at this address and need pages to back the VA we've allocated. As far as I understand it, these pages aren't being wasted because we're _using_ them as part of the stack. > AFAIK (looking at pmap output of a few processes of a B48/SPARC > machine) many processes never use all the stack they reserve by default. > Even if one process uses it's stack more extensively the others won't do > that, leaving lots of memory pages reserved but unused. I disagree with this statement. The anon reservation is made at the time the stack pages are allocated. This happens when we get a pagefault in the process' stack. The memory will only be reserved if it is going to be used by the process. This is because the pagefault occurs when the unmapped area of the stack is accessed. > Some (very wrong and raw) calculations: > Imagine a system has 50 processes where each process has a 8MB stack: > 50*8MB=400MB > If each process only uses 1MB of it's 8MB reserved stack memory you > "waste" ~~350MB (in theory) I'm not sure I understand where you're getting 8MB as a size for a stack? A random sample of processes that I pmap'd had a 16k-24k stack. > One option would be to reduce the default stack size - but that causes > trouble for applications which have been optimized to use more stack > (which adds some nasty error/failure cases anyway) - therefore it may > (IMO) be better to keep the current stack size at it's current value and > change the way how the stack memory is reserved The stack size is grown as needed. The memory isn't reserved until we grow the stack. > (since the average stack usage of all processes is _far_ below the > maximum stack size). Yes, and therefore the amount of anonymous memory reserved is, on average, much smaller than the maximum stack size. > Right... but in the case of a LiveDVD (which is mainly used for > demostration) it (AFAIK) matters more that it _runs_ on small machines - > the correctness is AFAIK secondary in this case (e.g. the "correct" > approach for a permanent installation would be the creation of a swap > slice and turn the proposed flag "off"). I think it needs to do both: run and be correct. Is there an actual problem you're seeing with a LiveDVD? -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] Thread balancing
> >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 0, 10, and 20 priority threads waiting for each CPU. > >Otherwise, all the low priority threads could pile up on and run on > >one CPU, while higher priority threads sit in another CPU's queue. > >The code tries to achieve a "parfait" sort of effect. :) > > But even in this case, it makes no sense to have one processor > completely idle, right? That's unlikely to happen. The idle() loop calls disp_getwork(). This function looks for a new task to run, and when appropriate, it may steal threads from other busy CPUs. -j ___ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
Re: [osol-code] dispq setup
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 dispq for a mp CPU (not cpu0) is called from
disp_cpu_init(). This function allocates a disp_t and assigns it to
cpu_disp. This is called from mp_startup_init() on x86 and
setup_cpu_common() on SPARC. mp_startup_init() is called from
start_cpu() which is called by start_other_cpus(). (start_other_cpus is
called from main()).
-j
On Tue, Jun 19, 2007 at 07:52:01AM -0700, Neale Ferguson wrote:
> As part of the startup of CPUs in mp_startup, struct cpu entries are
> created for CPUs (other than the boot cpu0). Each cpu area is zeroed
> and a call to disp_cpu_init() is made. It in turn calls
> cpu_dispqalloc() which has the following loop:
>
> cpup = cpu_list;
> do {
> disp_dq_alloc(&disp_mem[i], numpris, cpup->cpu_disp);
> i++;
> cpup = cpup->cpu_next;
> } while (cpup != cpu_list);
> num = i;
>
> Because the cpu structure has been zeroed the cpup->cpu_disp variable
> will be 0 (except for cpu0 which had been setup earlier to contain
> cpu0_dispq). In disp_dq_alloc() the pointer is used to set dptr->dp.
> Subsequently, a call to disp_dq_assign is made and the following code
> executed:
>
> dp = dptr->dp;
> dptr->olddispq = dp->disp_q;
> dptr->olddqactmap = dp->disp_qactmap;
> dptr->oldnglobpris = dp->disp_npri;
>
> ASSERT(dptr->oldnglobpris < numpris);
>
> if (dptr->olddispq != NULL) {
> /*
> * Use kcopy because bcopy is platform-specific
> * and could block while we might have paused the cpus.
> */
> (void) kcopy(dptr->olddispq, dptr->newdispq,
> dptr->oldnglobpris * sizeof (dispq_t));
>
> Because dptr->dp is 0 the value being loaded into dptr->olddispq is
> from location based off a zero pointer.
>
> Now considering this code is working for both x86 and sparc there must
> be something being setup that I haven't done for s390x. Can anyone
> give me a hint? I can't find anywhere where cpu_disp is being assigned
> except for cpu0.
>
> Neale
>
>
> This message posted from opensolaris.org
> ___
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
___
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
