On Wed, Jun 25, 2008 at 10:45, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote: > I'm guessing you mean one integer per semaphore, which would actually use > quite a bit of precious non-pageable kernel memory. Unless I overlooked something (I did the math by hand), sizeof(sem_entry) is 36 bytes (which makes the math in /src/system/kernel/sem.cpp, line 311, wrong). Adding an extra int32 makes it 40 bytes long, and would make the semaphore table 5MB big on a 1GB machine, instead of the current 4.5MB. I don't think it's that criminally wrong... > From BeOS experience this works rather well, actually. Come on :) It took a *lot* of time and hard work from the BeZilla team to make Firefox reasonably responsive under BeOS. Maddest props to Sergei and team, by the way! But we just can't assume every piece of ported software will receive the same level of dedication, specially in the case of software that uses portable toolkits like Qt and GTK. > There's actually little to tune. That it's not a good idea to run worker > threads with high priority is universally true. Quite true, but how about software that's born on a platform where priority levels are traditionally not messed with and whose kernel has lots of special-casing so that such software runs with any level of decent responsiveness, thus relieving the programmer from taking greater care in setting priorities? I won't have to resort to the "*cough* Linux *cough*" kind of jokes, will I? ;) > That there will be responsiveness issues is pure speculation on your part. > You're trying to cure a problem that might not even exist. Not cure; prevent. ;) > How about first > leaving that out and later *if* there turn out to be responsiveness problem > (or potential for optimization) tackle those? As I said on the previous message, it's a fundamental issue of fair schedulers. Either interactive threads get boosted because they didn't consume a full quantum, or they must get boosted by other means. Kiss a short and easy to understand scheduler goodbye if you choose the first route... > I'm not sure why you think your suggested optimization would make setting an > appropriate thread priority superfluous. It's not an *optimization*, it's a *method* of boosting. And it would not make it superfluous, only more relevant in the context of the application itself rather than the OS as a whole, since threads that actually go through a given code path will get boosted according to the code path followed, and not just per the programmer's discretion. > Sorry, not at all. Eh. ;) Cheers, A.