Re: [PATCH 2/7] fallocate() implementation in i386, x86_64 and powerpc
On Wed, Jul 11, 2007 at 12:10:34PM +1000, Stephen Rothwell wrote: On Wed, 11 Jul 2007 01:50:00 +0530 Amit K. Arora [EMAIL PROTECTED] wrote: --- linux-2.6.22.orig/arch/x86_64/ia32/sys_ia32.c +++ linux-2.6.22/arch/x86_64/ia32/sys_ia32.c @@ -879,3 +879,11 @@ asmlinkage long sys32_fadvise64(int fd, return sys_fadvise64_64(fd, ((u64)offset_hi 32) | offset_lo, len, advice); } + +asmlinkage long sys32_fallocate(int fd, int mode, unsigned offset_lo, + unsigned offset_hi, unsigned len_lo, + unsigned len_hi) Please call this compat_sys_fallocate in line with the powerpc version - it gives us a hint that maybe we should think about how to consolidate them. I know other stuff in that file is called sys32_ ... but it is time for a change :-) Maybe it would be worth to finally consider this: http://marc.info/?l=linux-kernelm=118411511620432w=2 ? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7][TAKE5] fallocate() on s390(x)
Index: linux-2.6.22-rc4/arch/s390/kernel/syscalls.S === --- linux-2.6.22-rc4.orig/arch/s390/kernel/syscalls.S 2007-06-11 16:16:01.0 -0700 +++ linux-2.6.22-rc4/arch/s390/kernel/syscalls.S 2007-06-11 16:27:29.0 -0700 @@ -322,6 +322,7 @@ SYSCALL(sys_getcpu,sys_getcpu,sys_getcpu_wrapper) SYSCALL(sys_epoll_pwait,sys_epoll_pwait,compat_sys_epoll_pwait_wrapper) SYSCALL(sys_utimes,sys_utimes,compat_sys_utimes_wrapper) +SYSCALL(s390_fallocate,sys_fallocate,sys_fallocate_wrapper) NI_SYSCALL /* 314 sys_fallocate */ You need to remove the NI_SYSCALL line. Otherwise all following entries will be wrong. SYSCALL(sys_utimensat,sys_utimensat,compat_sys_utimensat_wrapper)/* 315 */ SYSCALL(sys_signalfd,sys_signalfd,compat_sys_signalfd_wrapper) Index: linux-2.6.22-rc4/include/asm-s390/unistd.h === --- linux-2.6.22-rc4.orig/include/asm-s390/unistd.h 2007-06-11 16:16:01.0 -0700 +++ linux-2.6.22-rc4/include/asm-s390/unistd.h2007-06-11 16:27:29.0 -0700 @@ -256,7 +256,8 @@ #define __NR_signalfd316 #define __NR_timerfd 317 #define __NR_eventfd 318 -#define NR_syscalls 319 +#define __NR_fallocate 319 +#define NR_syscalls 320 Erm... no. You use slot 314 in the syscall table but assign number 319. That won't work. Please use 314 for both. I assume this got broken when updating to newer kernel versions. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] fallocate system call
On Thu, Apr 26, 2007 at 11:20:56PM +0530, Amit K. Arora wrote: Based on the discussion, this new patchset uses following as the interface for fallocate() system call: asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len) It seems that only s390 architecture has a problem with such a layout of arguments in fallocate(). Thus for s390, we plan to have a wrapper (say, sys_s390_fallocate()) for the sys_fallocate(), which will get called by glibc when an application issues a fallocate() system call on s390. The s390 arch specific changes will be part of a separate patch (PATCH 2/5). It will be great if some s390 expert can verify the patch, since I have not been able to test it on s390 so far. After long discussions where at least two possible implementations were suggested that would work on _all_ architectures you chose one which doesn't and causes extra effort. It was also noted that minor changes might be required to strace code to take care of different arguments on s390 issue. This is not limited to strace... Besides that the s390 backend looks ok. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] fallocate system call
On Fri, Apr 27, 2007 at 04:43:28PM +0200, Jörn Engel wrote: On Fri, 27 April 2007 14:10:03 +0200, Heiko Carstens wrote: After long discussions where at least two possible implementations were suggested that would work on _all_ architectures you chose one which doesn't and causes extra effort. I believe the long discussion also showed that every possible implementation has drawbacks. To me this one appeared to be the best of many bad choices. If one insists to have fd at first argument, what is wrong with having u32 arguments only? It's not that this syscall comes even close to what can be considered performance critical... Is this implementation worse than we thought? It adds userspace overhead for one architecture. Every *trace and *libc needs special handling on s390 for this syscall. I would prefer to avoid this. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
Even ARM prefers above kind of layout. For details please see the definition of sys_arm_sync_file_range(). This is a clean-looking option. Can s390 be changed to support seven-arg syscalls? Option of loff_t = high u32 + low u32 -- Matthew and Russell have suggested another option of breaking each loff_t into two u32s. This will result in 6 arguments in total. Following think that this is a good alternative: Matthew Wilcox, Russell King, Heiko Carstens Following do not like this idea: Chris Wedgwood It's a bit weird-looking, but the six-32-bit-args approach is simple enought to understand and implement. Presumably the glibc wrapper would hide that detail from everyone. s390 can be changed to support seven-arg syscalls. But that would require creating an additional stackframe in *libc to save original register contents and in addition it would make our syscall hotpath slower. That is because we have to take care of an additional register that might contain user space passed contents and needs to be put on the kernel stack. If possible I'd prefer the six-32-bit-args approach. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote: On Thu, Mar 29, 2007 at 10:10:10AM -0700, Andrew Morton wrote: Platform: s390 -- s390 prefers following layout: int fallocate(int fd, loff_t offset, loff_t len, int mode) For details on why and how int, int, loff_t, loff_t is a problem on s390, please see Heiko's mail on 16th March. Here is the link: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg133595.html Platform: ppc, arm -- ppc (32 bit) has a problem with int, loff_t, loff_t, int layout, since this will result in a pad between fd and offset, making seven arguments total - which is not supported by ppc32. It supports only 6 arguments. Thus the desired layout by ppc32 is: int fallocate(int fd, int mode, loff_t offset, loff_t len) Even ARM prefers above kind of layout. For details please see the definition of sys_arm_sync_file_range(). This is a clean-looking option. Can s390 be changed to support seven-arg syscalls? Wouldn't int fallocate(loff_t offset, loff_t len, int fd, int mode) work on both s390 and ppc/arm? glibc will certainly wrap it and reorder the arguments as needed, so there is no need to keep fd first. That would be fine for s390. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
On Fri, Mar 30, 2007 at 12:44:49PM +0200, Jörn Engel wrote: On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote: It does mean extra unnecessary work for 64-bit platforms, though... Wouldn't that work be confined to fallocate()? If I understand Heiko correctly, the alternative would slow s390 down for every syscall, including more performance-critical ones. That is correct. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] sys_fallocate() system call
On Mon, Mar 19, 2007 at 02:54:04PM +0530, Amit K. Arora wrote: On Fri, Mar 16, 2007 at 04:21:03PM +0100, Heiko Carstens wrote: On Fri, Mar 16, 2007 at 08:01:01PM +0530, Amit K. Arora wrote: asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len) Currently we have two modes FA_ALLOCATE and FA_DEALLOCATE, for preallocation and deallocation of preallocated blocks respectively. More modes can be added, when required. And these modes can be renamed, since I am sure these are no way the best ones ! :) Yes, the problem was adding compat wrapper for this. I will appreciate your help in writing it. Only thing is that we might have to wait till the order of the arguments is decided upon. Thanks! There is probably not much choice. If you want to stay with the loff_t arguments it won't work on 31-bit s390 or 32-bit powerpc dependent on the order of the arguments. So you should go for what Matthew Wilcox suggested: asmlinkage long sys_fallocate(int fd, int mode, u32 off_low, u32 off_high, u32 len_low, u32 len_high); That way it will work an all architectures and in addition no architecture has to do some magic to combine the splitted 64 bit arguments in compat mode. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] sys_fallocate() system call
On Sat, Mar 17, 2007 at 05:07:06AM -0600, Matthew Wilcox wrote: On Sat, Mar 17, 2007 at 08:59:05PM +1100, Paul Mackerras wrote: ... but wouldn't work on 32-bit powerpc. :( We would end up with a pad argument between fd and offset, giving 7 arguments in all (counting the loff_t's as 2), but we only support 6. Ditto mips and parisc. Can't be. Or: mips supports 7 arguments and parisc doesn't pad. Otherwise they couldn't have wired up sys_sync_file_range(int fd, loff_t offset, loff_t nbytes, unsigned int flags) But from what I read, it's currently not possible for 32-bit powerpc to wire up the already present sync_file_range system call. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
