This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: bumming cycles out of parse_identifier()...



On Tue, 11 Sep 2001, Neil Booth wrote:
> Linus Torvalds wrote:-
>
> > You can _trivially_ do that with mmap too.
> >
> > The only thing you need to do is to check if the length of the file is a
> > multiple of the page size, and if it is, you add one page of anonymous
> > mapping after the mapping of the file.  End of story - you get a '\0'
> > character at the end of the file for free 99.9% of the time, and the
> > remaining 0.1% of the time you just have to do one extra fixed mapping
> > at the end.  You already know the filesize through 'fstat', as you need
> > that for the mmap (and limit checking) anyway.
>
> Is this portable?

On any OS that has remotely usable mmap, yes.

Could you find OS's where it doesn't work? Probably. But you'd have to
look for them. I cannot think of any off-hand.

The biggest problem would probably be to figure out the page-size
portably. You are invocing "undefined" behaviour by touching bytes after
the end of the file, and I could imagine a system that has different sizes
for TLB entries, and could report a large page-size, while actually
handling partial mappings with smaller TLB entries (and then being unhappy
in between the small TLB entry and the next large one).

But I don't actually know of any such case. I can just imagine that they
could happen.

Anyway, it would probably be worth it to just try to optimize the read()
case, and see if it actually _is_ any slower than the mmap case. We can,
for example, imagine systems that do page mappings for properly aligned
read() calls too. Linux doesn't do it right now, but it's one of the
things that have been discussed, and it would at least in theory be faster
than mmap simply because you wouldn't have to fault the pages in.

So don't think that read() is automatically worse than mmap().

			Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]