LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 11-20-2004, 06:10 AM   #1
shy
Member
 
Registered: Dec 2002
Location: Russia
Distribution: ASP linux
Posts: 94

Rep: Reputation: 15
What are the drawbacks of syscalls and context switches?


What are the major drawbacks of invoking system calls and when do context switches decrease performance? As I see, any process eventually switches to another, but what actions can lead to additional context switches?
Can anybody post some links with a wide list of these drawbacks if it's possible? Any help would be highly appreciated!
 
Old 11-23-2004, 12:56 AM   #2
shy
Member
 
Registered: Dec 2002
Location: Russia
Distribution: ASP linux
Posts: 94

Original Poster
Rep: Reputation: 15
It seems very strange for me that no one knows... I so frequently meet the words "try to reduce the number of context switches" that I thought that the reason for it is well-known...
 
Old 11-23-2004, 01:47 AM   #3
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,481

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Perhaps was it you question is confusing.

Usually when you ask for drawbacks of something, it is to be compared with an alternative you do not suggest.

First, syscalls are always inducing a context switch, while context switches are not always a consequence of a system call.

Trying to reduce context switches, when possible, is certainly a good idea, as a context switch is consuming system resources and time which are lost by the application.

A good example is one application that need to read characters, one after one, from a file.
If you implement this with the system call read(fd,buf,1) or with the libc function fread(buf,1,1,fp), you'll notice huge difference in system load and performance.
 
Old 11-23-2004, 05:03 AM   #4
shy
Member
 
Registered: Dec 2002
Location: Russia
Distribution: ASP linux
Posts: 94

Original Poster
Rep: Reputation: 15
Well, as I see, context switch is only issued when one process occupies the CPU instead of another. Moving to and from the kernel space with system call is not a context switch, though it still is a expensive operation. Actually, AFAIK a context switch might occur when the process is waiting for a syscall to compete, if the kernel decides that the process has completed it's time slice, but it's not an additional context switch, but a scheduled (planned) one.

As this glossary points out,
Quote:
context switch
Refers to the changes necessary in the CPU when the scheduler schedules a different process to run on the CPU. This involves invalidating the TLB, loading the registers with the saved values, etc. There is an associated cost with such a switch, so it is best to avoid un-necessary context switch when possible. Note that the division of kernel-mode and user-mode means a similar, but simpler, operation is necessary when a syscall moves into kernel mode. However this is not called a context switch, as the mode switch doesn't change the current process. See lazy TLB. One good of feature of Linux is its extremely low context and mode switch cost, compared to an operating system like Solaris.
I'm not satisfied with "etc" in this quotation, and I'm trying to find out the complete list of operations. And their details, if it's possible. I found only some general words on this topic (like quoted before) in internet.

Quote:
Trying to reduce context switches, when possible, is certainly a good idea
Part of my questions was "how to reduce the number of context switches?", because when we know what introduces it (see my words: "what actions can lead to additional context switches?"), we can avoid it.

Another open question is "What's the difference between syscalls and context switches?"
 
Old 11-23-2004, 06:14 AM   #5
shishir
Member
 
Registered: Jul 2003
Location: bangalore . india
Distribution: openSUSE 10.3
Posts: 251

Rep: Reputation: 33
the context switch that he is talking about is not the process context switch but the switch from the user mode to kernel mode when a system call is invoked.

now lets see..
when you call a system call...the things that happen are an interrupt is raised and the cpu loads the code of the system call that runs purely in the kernel context...when its work is done, it loads back the user context(registers etal),

this running around between kernel and user space is an overhead that should be avoided..

eg: for memory: take a big chunk with one malloc and try to play around with the memory that you have obtained. this allows you to get memory from the pool that you have created instead of having to call malloc repeatedly.

PS: malloc even tho is a library call in turn calls 'brk' system call...

hope this has cleared up somethings

now to the process context switches...well your kernel's scheduler will try to give you the best process response...
a fair one to the best of its capabilities...now you have to decide how much ure process wants to sleep, how much it wants to call system calls....scheduler will try to have the best process running
 
Old 11-24-2004, 02:14 AM   #6
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,481

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Shishir explain it right.
One more comment:
Quote:
Part of my questions was "how to reduce the number of context switches?", because when we know what introduces it (see my words: "what actions can lead to additional context switches?"), we can avoid it.
You can totally avoid inter-process context switches by using a real-time scheduler and giving one process the higher priority. Of course, while being all beneficial for the elected process, it is not very friendly to the others, suspended until the first one terminates ...
That makes sense for certain tasks though.
 
Old 11-25-2004, 01:31 PM   #7
shy
Member
 
Registered: Dec 2002
Location: Russia
Distribution: ASP linux
Posts: 94

Original Poster
Rep: Reputation: 15
Actually I'm interested in what style a programmer should write a program to reduce the amount of CSes. What you have mentioned is a root's work, happening after the program was written.

I'm also interested in multiprocess programs, and real-time priority isn't a solution here.

I've found some points that answer my questions (at least partly), btw.
1. A CS can occur at the return from syscall (because schedule() is called there). If our process hasn't exhausted it's time slice, it will be chosen to run. If it has, then a common (not additional) context switch will occur. The latter case is similar to CS happening in the end of interrupt (in the most usual situation - in the end of a timer interrupt).
2. An additional CS occures when syscall decides to put the process in sleeping state. So, for example, I/O waiting syscalls are worse than non I/O waiting. So, one of CS-reducing practices would be "use non-blocking syscalls".
3. Simply speaking, the cost of syscall (and interrupt) involves the cost of switching to kernel mode from user mode and back, and the cost of saving/restoring cpu registers. CS always results from either syscall or interrupt, and adds additional cost of flushing TLB cache (on-processor cache of process' page tables) during the switch of virtual memory spaces (don't know, maybe it adds something else). Thus, another CS-reducing practice if to use multi-thread programs instead of multi-process, because their memory space is shared and switch from one thread to another doesn't involve TLB cache flush.
 
Old 11-25-2004, 02:03 PM   #8
jlliagre
Moderator
 
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris10, Solaris 11, Mint, OL
Posts: 9,481

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Quote:
I'm also interested in multiprocess programs, and real-time priority isn't a solution here.
One can argue you still can do it with a multi-CPU system ...

But I agree with your conclusions,

A process has little control on contexts switches, kernel settings have a lot.

Minimizing system calls tend reduce the number of CSs, as it gives less opportunities to the kernel to do them.

All other things being equals, multi-threading is superior to multi-processing, thanks to a reduced CS weight.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Context switches balteo Linux - General 0 09-06-2005 07:09 AM
messing with syscalls m00t00 Programming 2 11-27-2004 03:28 PM
Major Linux Drawbacks. rvijay Linux - General 57 10-03-2004 09:27 AM
Security Drawbacks Obie Linux - Security 10 05-25-2004 10:26 AM
rAPI with syscalls blietaer Programming 0 02-02-2004 02:49 AM


All times are GMT -5. The time now is 06:34 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration