If there was numerous issues, sure. But every time we get to the point
where it seem that that is necessary we find a workaround.
Right now, this is the ONLY issue we got..
> > 2. We're making a MPI library, and as such we don't have any control
> > with the application.
>
> LD_PRELOAD
>
IN general LD_PRELOAD is fun for testing and academic programs, but not
for production code.
In specific you run into a problem with how fortran 90 compilers do
dynamical arrays. It's very compiler dependent.
> > 3c. It's therefore necessary for HW to access user pages.
>
> Like TV cards do. That isnt hard
>
nobody said it is.
> > 4. In order to to 3, the user pages must be pinned down.
> > 5. the way MPI is written, it's not using a special malloc() to allocate
> > the send receive buffers. It can't since it would break language binding
> > to fortran. Thus ANY writeable user page may be used.
>
> Well not all the pages are guaranteed DMAable, so I guess you already
> lost.
>
Nope. The drivers test to see if the page is DMAable, and do a copy if
necessary. Most of the high performance interconnects NIC's do 64 bit
PCI.
> > 10. kernel patches are impractical, I must be able to do this with std
> > stock, redhat, AND suse kernels.
>
> So you want every vendor to screw up their kernels and the base kernel
> for an obscure (but fun) corner case. Thats not a rational choice is it.
> You want "performance is everything" you pay the price, don't make
> everyone suffer.
No! I don't disagree with removing the export of the syscall_table!
I just want the "proper mechanism" indicated by Arjan in the changelog.
Pls read this thread. There are legitimate uses to having syscall
hooks/notifications, either you think mine is or not.
-- _________________________________________________________________________Terje Eggestad mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com
Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/