Re: performance implications of releasing resources and context switches
- From: Rainer Weikusat <rweikusat@xxxxxxxxxxx>
- Date: Tue, 29 Jul 2008 11:15:24 +0200
Ambrose Silk <silky@xxxxxxxxxxxxxx> writes:
[...]
Files are mapped rather than fopen-ed because that costs exactly 4
system calls per file (open, mmap, munmap, close) as opposed to
fopen/fread/fclose which might do any number of read calls.
Unless you know the filesize, there must be a (f)stat missing in this
list. And you can save one (two) system call(s) by not using mmap:
open, fstat, read, close (as opposed to open, fstat, mmap, (madvise),
munap, close). Assuming your file accesses are read-only, there should
be a filesize up to which copying the data is faster than having the
kernel make it accessible after a page fault[*]. If your checksumming
operation can work on blocks of data not larger than the size of the
L1 cache, using read would have the additional benefit that the
contents of the cache would already be loaded during the copy
operation.
[*] This is claimed in 'The Design and ... FreeBSD Operating
System' somewhere and the size is IIRC 16K.
.
- Follow-Ups:
- Re: performance implications of releasing resources and context switches
- From: Ambrose Silk
- Re: performance implications of releasing resources and context switches
- References:
- performance implications of releasing resources and context switches
- From: Ambrose Silk
- Re: performance implications of releasing resources and context switches
- From: David Schwartz
- Re: performance implications of releasing resources and context switches
- From: Ambrose Silk
- performance implications of releasing resources and context switches
- Prev by Date: Re: TCP server eating up the whole CPU
- Next by Date: Re: TCP server eating up the whole CPU
- Previous by thread: Re: performance implications of releasing resources and context switches
- Next by thread: Re: performance implications of releasing resources and context switches
- Index(es):
Relevant Pages
|
