[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47425470.2000608@redhat.com>
Date: Mon, 19 Nov 2007 19:28:48 -0800
From: Ulrich Drepper <drepper@...hat.com>
To: "H. Peter Anvin" <hpa@...or.com>
CC: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
mingo@...e.hu, tglx@...utronix.de, torvalds@...ux-foundation.org
Subject: Re: [PATCHv3 0/4] sys_indirect system call
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
H. Peter Anvin wrote:
> What bothers me about the sys_indirect approach is that it will get
> increasingly expensive as time goes on, and in doing so it does a
> user-space memory reference, which are extra expensive. The extra table
> can be colocated with the main table (a structure, in effect) so they'll
> share the same cache line.
You assume that using sys_indirect will be the norm. It won't. We
mustn't design system calls deliberately wrong so that they require the
indirection.
Beside, if the number of syscalls which has to be handled this way grows
we can use something more efficient for large numbers of test than a
switch statement. It could even be a word next to the system call table.
But I still don't see that the magic encoding is a valid solution, it
doesn't address the limited parameter number. Plus, using sys_indirect
could in future be used to transport entire parameters (like a sigset_t)
along with other information, thereby saving individual copy operations.
I think the sys_indirect approach is the way forward. I'll submit a
last version of the patch in a bit.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHQlRw2ijCOnn/RHQRApifAKDE1nZqRbm4cJxbhobBb7jCx1T00QCgiSa0
EXKjL2Gwu3atSLSD+Rb4yO4=
=6ZGt
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists