From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Yury Norov <ynorov@caviumnetworks.com>,
Florian Weimer <fw@deneb.enyo.de>
Cc: Chris Metcalf <cmetcalf@mellanox.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] Consolidate Linux readahead() implementations
Date: Fri, 23 Sep 2016 13:32:00 -0000 [thread overview]
Message-ID: <b304b364-77dc-0fce-ba99-f4e68443b0a8@linaro.org> (raw)
In-Reply-To: <20160923124456.GA22674@yury-N73SV>
On 23/09/2016 09:44, Yury Norov wrote:
> 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.
>
Indeed, unfortunately tile seems to get its own readahead definition.
However I think it should not prevent us to use my previous strategy,
we can follow the SH example for pread (where it adds a dummy argument
before offset), and do something as:
sysdeps/unix/sysv/linux/tile/readahead.c
#include <sysdep.h>
#ifndef _LP64
/* Although tile 32-bit ABI passed 64-bit arguments in even registers,
readahead interface does not follow this convention. */
# undef __ALIGNMENT_ARG
#endif
#include <sysdeps/unix/sysv/linux/readhead.c>
next prev parent reply other threads:[~2016-09-23 13:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-22 20:44 Yury Norov
2016-09-22 20:59 ` Dmitry V. Levin
2016-09-22 21:26 ` Adhemerval Zanella
2016-09-22 21:36 ` Adhemerval Zanella
2016-09-22 23:21 ` Yury Norov
2016-09-23 6:08 ` Florian Weimer
2016-09-23 12:45 ` Yury Norov
2016-09-23 13:32 ` Adhemerval Zanella [this message]
2016-09-23 14:12 ` Yury Norov
2016-09-23 14:24 ` Adhemerval Zanella
2016-09-23 15:45 ` Yury Norov
2016-09-23 19:50 ` Adhemerval Zanella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b304b364-77dc-0fce-ba99-f4e68443b0a8@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=cmetcalf@mellanox.com \
--cc=fw@deneb.enyo.de \
--cc=libc-alpha@sourceware.org \
--cc=ynorov@caviumnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).