From: Scott Lurndal on
Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> writes:
>scott(a)slp53.sl.home (Scott Lurndal) writes:
>
>> jt(a)toerring.de (Jens Thoms Toerring) writes:
>>>In comp.unix.programmer Jasen Betts <jasen(a)xnet.co.nz> wrote:
>>>> select() prefers the lowest numbered file descriptor it's asked to
>>>> test/watch so that should be easy to arrange,
>>>
>>>Just curious: in what sense does select() "prefer" lower numbered
>>>file descriptors?
>>
>> for(i=0; i < num_file_descriptors; i++){
>> if (pending_select[i].is_ready) {
>> return i;
>> }
>> }
>
>That isn't select() having a preference, it's you having a preference.

True. Or the kernel writer having a preference and posting only the
first event rather than collecting all before returning (although
poll(2) and select(2) both require that all events at the time of
the system call be reported).

scott
From: Scott Lurndal on
"Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>If you don't explain your reasoning then your advice is
>useless to me.

Because it takes more than a few postings to a usenet newsgroup
to familiarize you with the idiosyncratic behavior of modern
processors and memory controllers.

David's been pretty patient. Most of the rest of us don't have
time to provide you with a free education. Audit a college
level computer architecture course and then come back with
your questions.

And I'd argue that you want threads, not processes, if you
want to reduce the impact of context switching on your
data cache and TLB's.

scott
From: Scott Lurndal on
"Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:

>I just checked the third party provider provides UPS. Most
>experts seem to say not to worry about the disk drive's
>onboard cache if UPS is available.

I would argue this. A reboot may blow the drive cache away before
it is synchronized to disk. I suspect you're confusing with drive
write caches used in RAID subsystems (e.g. DG/EMC Aviion, EMC symmetry),
where there is additional control hardware to ensure that the
cache is flushed when the transition from mains to batteries occurs.

Most server quality drives do not enable write caching. If you're
using an inexpensive SATA desktop drive, you can turn write caching
off with 'hdparm(1)'.

scott
From: Peter Olcott on

"Scott Lurndal" <scott(a)slp53.sl.home> wrote in message
news:n1rvn.76524$K31.47278(a)news.usenetserver.com...
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>>
>>If it does not do it by sequencing (the easy way) Then it
>>uses some sort of locking mechanism (the slower more
>>difficult way)?
>>
>
> Why would you conclude that a locking mechanism is slower
> and
> more difficult?
>
> scott

All of the multiple concurrent access issues simply go away
with channeling all file access through a single process.
This can be faster or slower depending upon required access
patterns.


From: Peter Olcott on
I don't want to reduce the impact of context switching. I
want to make one set of jobs (paying customers) have
absolute priority over another set of jobs (free trial
users). It may be close enough to simply give the high
priority jobs much higher process priority than the lower
priority jobs.

"Scott Lurndal" <scott(a)slp53.sl.home> wrote in message
news:T8rvn.76526$K31.33691(a)news.usenetserver.com...
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>>If you don't explain your reasoning then your advice is
>>useless to me.
>
> Because it takes more than a few postings to a usenet
> newsgroup
> to familiarize you with the idiosyncratic behavior of
> modern
> processors and memory controllers.
>
> David's been pretty patient. Most of the rest of us
> don't have
> time to provide you with a free education. Audit a
> college
> level computer architecture course and then come back with
> your questions.
>

I don't have time for that, but, I did buy a bunch of books:
Understanding the Linux Kernel, Third Edition
was my latest purchase.

> And I'd argue that you want threads, not processes, if you
> want to reduce the impact of context switching on your
> data cache and TLB's.
>
> scott