stat very inefficient
All of the *stat*() syscall routines copy the inode attributes around a whopping _3_ times before they get to userspace.
1) From inode to "struct kstat"
2) From "struct kstat" to "struct stat{,64}" on local kernel stack
3) From local kernel stack to userspace
That's rediculious. And also the stores into the various structures are not done in ascending order and thus all of the store buffers on various cpus never get a reasonable store stream for maximal store buffer compression.
The reason things happen this way is that each implementation of the various stat structures have padding in different places and/or have other layout issues. The simplest thing to do is memset() the thing, fill in the non-pad parts, and copy it into user space.
We should be able to do this with just 2 copies as I recognize the reason why the struct kstat abstraction exists.
I was about to make sparc64 specific copies of all the stat system calls in order to optimize this properly. But that makes little sense, instead I think fs/stat.c should call upon arch-specific stat{,64} structure fillin routines that can do the magic, given a kstat struct.
Comments?
Quoted 7 lines · David S. Miller
I was about to make sparc64 specific copies of all the stat system calls in order to optimize this properly. But that makes little sense, instead I think
fs/stat.cshould call upon arch-specific stat{,64} structure fillin routines that can do the magic, given a kstat struct.Comments?
I'm not sure that it's worth doing for anything below the "widest" version of stat. For that one - yeah, no objections.