Date: Wed, 19 Jan 2005 09:19:29 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: ryans@gamersimpact.com Cc: Felix.Schalck@gmx.net Subject: Re: Kernel mode programming Message-ID: <20050119.091929.63840290.imp@bsdimp.com> In-Reply-To: <41ED14B0.8070600@gamersimpact.com> References: <002201c4fd4a$c5a81230$0700a8c0@felix> <41ED14B0.8070600@gamersimpact.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <41ED14B0.8070600@gamersimpact.com>
Ryan Sommers <ryans@gamersimpact.com> writes:
: - Felix - wrote:
: > Hi everyone,
: >
: > Doing lot of syscalls interrupts in a soft seems to take quite a long time, and seriously slow performances. As far as you can't reduce the syscall amount, is there any way to run apps in kernel mode, in order to call sysfonctions directly ? Perhaps by re-writing softs in kernel modules ?
: >
: > thanks for your time.
:
: Yes, it is possible to write loadable kernel modules. As far as if your
: programs can be rewritten as kernel modules and achieve better
: performance that's entirely dependent on what you are doing. What type
: of syscalls are you executing? What is the rate at which you are calling
: them? If you are calling a syscall on the same arguments thousands of
: times could you implement some sort of cache system for syscall results?
:
: In my opinion it's bad practice to just throw a program into the kernel
: to get better performance without evaluating why the performance is bad.
: Making it a kernel module invites all kinds of security and stability
: issues.
And to be honest, it is rarely necessary. I say that as someone who
has to deploy to 486/Pentium 133MHz machines for an embedded product.
There's no subsititute for thorough understanding of the problem or a
redesign of algorithms to make them do lest work. The overhead for
kernel calls is so low (typically < 1-5%) that moving it into the
kernel should only be done when you have an atypical case, or if
there's a real-time or near-real-time component. Hearing about huge
number of syscalls causing problems usually means that the caller
needs to reevaluate how things are being done.
One area where I have optimized is making the syscalls do more
individual work. Rather than having a read interface that returns all
the data, have one that returns ranges of an mmap'd region of memory
and have the caller then schedule the writes from that region of
memory. This technique saves a lot of data copying, for example.
The scsi target code uses this technique, for example.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050119.091929.63840290.imp>