public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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>

  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).