On 16Mar2010 09:02, "Martin v. Löwis" <martin at v.loewis.de> wrote:
| > If it's lurking behind a filesystem interface or in its daemon mode
| > (remote archive store), multiple client processes can be using it at once,
| > and it will be processing multiple tasks somewhat in parallel. Here one
| > can get a compute bound thread answering one request, impacting quick
| > response to other parallel-and-cheap requests.
|
| However, "impacting" will always be the case. *Of course* any thread
| that performs computation impacts everything else on the same processor.
| There is nothing to prevent that, unless you schedule the long-running
| activity at a point in time where you know the system will be idle for
| the entire run of that task.
Sure, but one has only to dip one's toe in the long running Linux
interactivity scheduling wars to know that there's a _lot_ of attraction
in a scheduling approach that favours the usually-blocked task over the
CPU bound task, and various approaches like the early low-latency patches
to the later in-the-scheduler changes were greeted with much rejoicing.
Certainly there's only so much CPU to go around, but if the tasks blocked
waiting for something to happen get to run more immediately when an event
does occur, you tend to get better "responsiveness".
Cheers,
--
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
Be smart, be safe, be paranoid.
- Ryan Cousineau, courier at compdyn.com DoD#863, KotRB, KotKWaWCRH
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4