From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22466 invoked by alias); 23 Sep 2016 12:45:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 22312 invoked by uid 89); 23 Sep 2016 12:45:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:mail-bn, H*r:104.47.33 X-HELO: NAM01-BN3-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Fri, 23 Sep 2016 12:45:00 -0000 From: Yury Norov To: Florian Weimer CC: Chris Metcalf , Adhemerval Zanella , Subject: Re: [PATCH] Consolidate Linux readahead() implementations Message-ID: <20160923124456.GA22674@yury-N73SV> References: <1474577068-1781-1-git-send-email-ynorov@caviumnetworks.com> <827f758c-b744-22f2-5dbb-4471208cd6b2@linaro.org> <20160922232119.GA12837@yury-N73SV> <87k2e3jgh8.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <87k2e3jgh8.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: AM3PR03CA015.eurprd03.prod.outlook.com (10.141.191.143) To DM3PR07MB2252.namprd07.prod.outlook.com (10.164.33.150) X-MS-Office365-Filtering-Correlation-Id: 9761ef67-9c6a-4e92-c4b6-08d3e3af71f4 X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;2:v+Fnli/M823N5gldn5vAxEXGiI1xD6KMbHp0Zbhv172SMqZ+tOYnkee4lmMI5dmkGTvVifgfNh07dC761wcOEGmFd6ZnZygFf5rpdjbhMEGH51rVpOP6dTN4aipnDTuoR3m0f41lVjQwVAVeXr6bgPZEA+3i8BB6E2aNHi3Ep7U0VrlaGXpz8fXWuk2DjRzx;3:hVrPxjBmGUUV6AplJki4NLYzU/P9843teLQk9ZEdJcdqwjOJ1J47JFLSKa8GH9pWYGIk3GXtv5sYp5rTZmm4ZTdo0QL4f9EX7wSmoNhY4J4A8nSETc6M0O+99m156+jO;25:q4TcSdGYv0V5vKeRSEg6twLfK3RjXshAfm6xEBWR3KDchqDwIAsPt3d5+FwJj8KZJQGefC80ttCAASZTXQn9O2I6mMi2OR4lQL7VqOXQRCKUw/OG88QKDP3a3JyAoQZWVfmhfu69mbR+gVXysb5QuiKvarr6HnQoOnWHxNJFAF5m8/NIU4TmJvxr2io03gzbvcapYj0kDpjWuOt6Xy6ngwRx15/a6ZEL8COl8kK0ft43lA8oVZCXdllzhSHL7LbV1CebjdjnFG03GqZ6vq6WEnLw+tLAwNRU7pJiwc/XbMatpqk2eoKMnU1FajD8oTDqJT2sXHLYT0pzmCcSvMXe5etKZ6DzvUJO6cmE+stgu+7+mhi/JU96NWwrXwOjJDS4vJV6+RW2yzT2Zx+eoax7QGu3APY2l3lYSrtQeaVpE88= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;31:/uPPcJFgb7iYlltcJvZ6/TpYZzhb6E54wr9mftLSVWpZfUS0c0qEOA0/eIYqktG81kDnuSGbaI0cywmWi/Qky9liO/fy7CUVcbLSymamiFrj+VCX3xwEJ7LkfJTam9nkIQJwetemkUT28aeTlHyDVb9eSDugSnkhNAEDu1BE8O0U9bFQs4h6J4GLiKoJg3VGnhlDzNeubGWix68GzoqlIvLqdRGJU8yhWj3JMk51Plk=;20:lt5QeCh2LRulUd3fVpqRkeUhB1JG5Pnxq3+N63VeDUahxt6zN+ibXDW9rcheaJTJtQknKgal7BwiXCqGxJZtgCCxA08CObcPt5V9oVIwNTGSYedSN5gr/+zuQzbzewyiTluvQRkZBDDIE2SIdji+shY2QPy7wOQ6BdzLpIRcLd9s5hy5aDcEsoD/P64qj1vJmli8Q5YUS3qbuhyMsiD8WWhX03V5Ov0rRE44gYnTdJwcEx3qKybwAbZgLYR5DQNR9uNKyGYHJ3QwkeRf+YgdIElX5pFgAS7WA4xlkfBZfon8TnQUDMEeuYNthSOYwV1d6i47TqFZL3TNtItQb8UakRbtZvqAA8zo6m5jQ0HwDDZEtFkVLnbzRpnQl4KEO6vpZ5enYJ9P84V9svLoGKe51OB4DqvwSXDqe6VNc/qL7cTKIBIyCSOdQajxTsau0PpKbPUGiTz1u8XEAvcUEpkmtvPMREwbgdXEjM3kURe58z3XOneRdg+8PeYqJinfexg1MMEd9KwcYx7pSwjiSeY1q7GG4KwUvDs9tGvtt3aAZzmojr5smaon43hsmEsMBn9KFDl0vFNfDDS1q00DWeQUn8jWCgx1zOcP3f5le5rNUKc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);SRVR:DM3PR07MB2252;BCL:0;PCL:0;RULEID:;SRVR:DM3PR07MB2252; X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;4:ORaqSxl2hJSYUPnK+PYzyWwY8SFj5Lu/m+z/sx7qGoaXB3qoR8e3dzHs7aJjBs10PKaNRjmfoY7B8XpLYL3OCNGTQd0m0QCpMItJv35x3yiaowOepd/YaF3+U4LP/EM2/moCir7IGvvNb0HrjlXol1qr7Ag+FGWMRYetQw0zm4Cer2HRQ15xmSyNoVMkhF0KrxIXmpk8tbFc8wAglhEoNscdM81dCGTzQWhTkAb6lZlbfvg+aviA+cgrsk8CeAmMu1GyZHOAN61bkJyK+hQBtvQ6IQmj+/pBcd4nNgcQraTYm2My8ba/GOKRuhW06QpEDSkhrCvS4jxs1vXl8aREPv3vWMSgvQnLZmq/d9GIF8GkhqqMJS3XWe+ZR5+u4XAn X-Forefront-PRVS: 0074BBE012 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(199003)(189002)(24454002)(77096005)(2950100001)(305945005)(66066001)(9686002)(110136003)(83506001)(15975445007)(47776003)(92566002)(42186005)(46406003)(105586002)(106356001)(76506005)(7736002)(7846002)(93886004)(189998001)(19580395003)(76176999)(54356999)(97736004)(50466002)(4326007)(97756001)(4001350100001)(33716001)(2906002)(6116002)(33656002)(3846002)(68736007)(5660300001)(8676002)(23726003)(1076002)(101416001)(50986999)(586003)(81156014)(81166006)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:DM3PR07MB2252;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: caviumnetworks.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM3PR07MB2252;23:MHXu/hlZo7VcFYYSRKgU39qpD9/sbYnenkab2t+A4?= =?us-ascii?Q?+NFwee7tcAqzOTv5cuo5mNSMVQ9wvZjOxOqw0zDRkC45b4gjPE+wuMbtTbyT?= =?us-ascii?Q?fCSohfkc3UE3qbIkZTafKsHHhQ5lYmp9epYUfwtu1QvZO4pa1n6DAT+XbYvM?= =?us-ascii?Q?zAKJky3lbZrTSVhUcqO7gFV1vEIeUA7gwkwC0GpEBOL675I0JrbEAuyxffx3?= =?us-ascii?Q?2iyTBPAOgeyCO3+iBn5CsgGLfaOc++gqvJugqarACCnQXCRmdKW6ktlgmVNv?= =?us-ascii?Q?VLewFBdL4CVvTGObKHT7i+Quc72zllC4/i/wh4aUwdGAmLAY+SKZGVop0PGD?= =?us-ascii?Q?4Fl0xG+V6VJzHIpBp+pnZtTpzcvyIt7WloGwiQPZbYWvd9wX6JDMWlS7eLrE?= =?us-ascii?Q?I8Pkg9jveGGC3fe4/Gvsq4v/0A//QYaUb17hju0IBp6/UIp2BFuUEsUquT07?= =?us-ascii?Q?DK/97ewoDCvP09twh1KR1q9s4dnxPz3bfckB9NaERQZL7TVCa8R64YtEUm9S?= =?us-ascii?Q?yT6e1gLc/xWeTxw7ryEuhniOs/4hsxB8EujeEw4BOAw9k+qETgsFQzq1CuOm?= =?us-ascii?Q?PhqV0j9kD56B05Ti1q0LDrNSN4mlKd3L09/PF/pAiFbz4XK+AJ/TCpdw+LJJ?= =?us-ascii?Q?yojdEpxmeqWmgPQUGX2elkiXcdkaYfR9YG15fvoOjJphOsa92WMDErOvdX5s?= =?us-ascii?Q?otpezKeGWEGDgORo3mVqdj5jQqRmypa0u8GMHnLcmdeF/b3k8KstQDR2a+3k?= =?us-ascii?Q?TY1/gpKpIEtWbnxQ000Ji7NS7UNys1WjldCTk6+jWQD7u0+ZNzNPa2ldimxP?= =?us-ascii?Q?DcjYbaDNY8O3avVQsf9BBaqvvU+mFpbc5WxF7IfivOSmvE01fEEak0jxfPvz?= =?us-ascii?Q?g4iZjFxXIurn9AnPfjqB5s1BwruahkBfBelL7+3NOhIrZW6qLc40SwOn0rsw?= =?us-ascii?Q?PrWoV+9XZmA2r8L2zX781wtv/LtQyIVDxuWbJQyQozCMD+bVOTd6rSXU0pLW?= =?us-ascii?Q?catBMrghZFHvoL9+ZVPOQWPj+0PQqYuciy+m6VOaOkWYFjnPSPVfzMzotTBG?= =?us-ascii?Q?eGm/GfFxEe24NolcqpbGfrKzE1SPI2Hd642fSvfefOEHyvq4I7gtFSelsycd?= =?us-ascii?Q?eC4qd3UpuWR4+pz9FemC+4nCDtzPPg6fh9RK4sw5nEIQ4MM394FnsdgMs4Ak?= =?us-ascii?Q?XXFLP4+6IBkFgXZKUra3/sob3CaY7zZv52o2/BigjVqFNWVjoBymMk/mTg8H?= =?us-ascii?Q?te7tk+E0BYPQlqK/rE=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM3PR07MB2252;6:VqyuxrBnqVHv12sDmkhNBeDhSd//fV2cSwkPxcHUyI0MY3GPdPuWtPrju7geY5qHZBxBBzJ+oMJSiGEcrTSieWSgVPqIlyM3OKs9j3pQXBlvoOJB1ld1w5cE0kJARiuiJQyW9AR/I9uZ8IrS+yao6GWzffavqMLduFHGckTnqlpIHqvFqHcDM8LSpK4o/Ak/ffekRDxesOJifNOwPcv8yyN1IXV/fjwWlTCYlfmj+YdhcHw8BMk0K6qMLZhq8Z/LSTK+fHGTrRLNf6Tth/QH1VDEwy+V023WpUkfOuWoiIo=;5:NeVJ2hcYRfgRV+7uYTMoZOtzL35OLRmgQwvgOmytmI7tJjBjIEPBQ9yPI8CHIb91bphiRXLdaJcXe6toVo+5j1EI8+1im2AqLQyI1lk56+V6V3HgrfcKP6peL7EZu98FrVQb8ttlm2I8wFtr7RMJ9A==;24:HIXIMWjkrxi3De8McAZD90wGuk1Kyl0C/cpah8vK47S2mgxPL4j9Sp9xES1TMH0Td0mZ/ENyCPpD5+xI7mSWzq1Dn9AFqfJIEFc2cXZU6Ck=;7:apDgZuPzVdC5oik9Jk/gsPeSo5c7yk8tMMnf430DPNGii/fyHYfUWVZiNib+cV3I/IH595l5fk3hsoIzebSOxSDrYEHXW2U3G6Vo3E5RzYt7V01X0PNwUFPZ6FNb4M2F5Ar41+PmX1Z3XRCpI0LOBxQ2Z+yO4fMbiNpR+spl0QgfPnUzh7dKxRAxmN2usp+DB7rDxyxCgpMjXx49hRvLs8t4qTQd00qIDDTmsBGoiYc9Eynbln/kY4MVOnzVHXDev4nyu3iOyHRWITiQF5stg576JVvUeSe9d36lECsiMTg54CweZTNFJ1RKgspSxyqn SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2016 12:45:05.6277 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR07MB2252 X-SW-Source: 2016-09/txt/msg00490.txt.bz2 On Fri, Sep 23, 2016 at 08:08:19AM +0200, Florian Weimer wrote: > * Yury Norov: > > > On Thu, Sep 22, 2016 at 06:36:22PM -0300, Adhemerval Zanella wrote: > >> Hi Yury, some comments below. > >> > >> On 22/09/2016 17:44, Yury Norov wrote: > >> I think we can use SYSCALL_LL64 plus __ALIGNMENT_ARG here. The tricky is to pass > >> the correct argument size, since it used by the macro to select the correct > >> arch-dependent one. This is exactly why I proposed the patch to add > >> {INTERNAL,INLINE}_SYSCALL_CALL [1], readahead will be simplified to just: > >> > >> ssize_t > >> __readahead (int fd, off64_t offset, size_t count) > >> { > >> return INLINE_SYSCALL_CALL (readahead, fd, > >> __ALIGNMENT_ARG SYSCALL_LL64 (offset)); > >> } > >> > >> I suggest you to wait the {INTERNAL,INLINE}_SYSCALL_CALL patch to land and > >> based this one on it. I think I addressed most of Florian comments, I just > >> need to check if assembly generated using the new macros is the same as > >> before (which I expect to). > >> > >> [1] https://sourceware.org/ml/libc-alpha/2016-09/msg00452.html > > > > __ALIGNMENT_ARG is controlled by __ASSUME_ALIGNED_REGISTER_PAIRS, > > as well as __ALIGNMENT_COUNT(). Currently we have 4 ports that > > enable it: mips, arm, powerpc and tile. Mips and arm pass 5 arguments, > > so __ASSUME_ALIGNED_REGISTER_PAIRS is what they need. Powerpc uses > > syscalls.list (thanks for pointing it), and so is not affected by this > > change. But tile is still in case. Is my understanding correct that it > > uses linux/readahead.c as implementation? If so, this patch will break > > tile ABI. That's why I introduced new option. > > > > So, as for me we cannot use __ASSUME_ALIGNED_REGISTER_PAIRS because of > > tile. Is it correct? > > Does readahead even work on tile today? Maybe it's already broken and > this change fixes it. :) > > Chris? In kernel 32-bit tile expects 4 arguments: arch/tile/kernel/sys.c: 61 #if !defined(__tilegx__) || defined(CONFIG_COMPAT) 62 63 #ifdef __BIG_ENDIAN 64 #define SYSCALL_PAIR(name) u32 name ## _hi, u32 name ## _lo 65 #else 66 #define SYSCALL_PAIR(name) u32 name ## _lo, u32 name ## _hi 67 #endif 68 69 ssize_t sys32_readahead(int fd, SYSCALL_PAIR(offset), u32 count) 70 { 71 return sys_readahead(fd, ((loff_t)offset_hi << 32) | offset_lo, count); 72 } 73 74 int sys32_fadvise64_64(int fd, SYSCALL_PAIR(offset), 75 SYSCALL_PAIR(len), int advice) 76 { 77 return sys_fadvise64_64(fd, ((loff_t)offset_hi << 32) | offset_lo, 78 ((loff_t)len_hi << 32) | len_lo, advice); 79 } 80 81 #endif /* 32-bit syscall wrappers */ So it seems we have no chance to consolidate getdents() completely w/o new option. If no objections, I'll send v2 with removing getdents from powerpc syscalls.list, and rework new option in more suitable way. Objections? Yury.