On Wed, May 15, 2019 at 12:04 PM Christian Brauner wrote:
> This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
> pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
> process that is created via traditional fork()/clone() calls that is only
>
This adds the pidfd_open() syscall. It allows a caller to retrieve pollable
pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a
process that is created via traditional fork()/clone() calls that is only
referenced by a PID:
int pidfd = pidfd_open(1234, 0);
ret =
This adds testing for the new pidfd_open() syscalls. Specifically, we test:
- that no invalid flags can be passed to pidfd_open()
- that no invalid pid can be passed to pidfd_open()
- that a pidfd can be retrieved with pidfd_open()
- that the retrieved pidfd references the correct pid
On Mon, 13 May 2019, Masahiro Yamada wrote:
> As of Linux 5.1, alpha and s390 are the last architectures that
> have defconfig in arch/*/ instead of arch/*/configs/.
>
> $ find arch -name defconfig | sort
> arch/alpha/defconfig
> arch/arm64/configs/defconfig
> arch/csky/configs/defconfig
As of Linux 5.1, alpha and s390 are the last architectures that
have defconfig in arch/*/ instead of arch/*/configs/.
$ find arch -name defconfig | sort
arch/alpha/defconfig
arch/arm64/configs/defconfig
arch/csky/configs/defconfig
arch/nds32/configs/defconfig
The only difference between the generic and RISC-V implementation of PTE
allocation is the usage of __GFP_RETRY_MAYFAIL for both kernel and user
PTEs and the absence of __GFP_ACCOUNT for the user PTEs.
The conversion to the generic version removes the __GFP_RETRY_MAYFAIL and
ensures that
Hi,
Many architectures have similar, if not identical implementation of
pte_alloc_one_kernel(), pte_alloc_one(), pte_free_kernel() and pte_free().
A while ago Anshuman suggested to introduce a common definition of
GFP_PGTABLE and during the discussion it was suggested to rather
consolidate the
parisc allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The pte_free_kernel() and pte_free() versions on are
The nds32 implementation of pte_alloc_one_kernel() differs from the generic
in the use of __GFP_RETRY_MAYFAIL flag, which is removed after the
conversion.
The nds32 version of pte_alloc_one() missed the call to pgtable_page_ctor()
and also used __GFP_RETRY_MAYFAIL. Switching it to use generic
The hexagon implementation pte_alloc_one(), pte_alloc_one_kernel(),
pte_free_kernel() and pte_free() is identical to the generic except of
lack of __GFP_ACCOUNT for the user PTEs allocation.
Switch hexagon to use generic version of these functions.
Signed-off-by: Mike Rapoport
---
alpha allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The alpha pte_free() and pte_free_kernel() versions are
The PTE allocations in arm64 are identical to the generic ones modulo the
GFP flags.
Using the generic pte_alloc_one() functions ensures that the user page
tables are allocated with __GFP_ACCOUNT set.
The arm64 definition of PGALLOC_GFP is removed and replaced with
GFP_PGTABLE_USER for
Most architectures have identical or very similar implementation of
pte_alloc_one_kernel(), pte_alloc_one(), pte_free_kernel() and pte_free().
Add a generic implementation that can be reused across architectures and
enable its use on x86.
The generic implementation uses
GFP_KERNEL |
Replace __get_free_page() and alloc_pages() calls with the generic
__pte_alloc_one_kernel() and __pte_alloc_one().
There is no functional change for the kernel PTE allocation.
The difference for the user PTEs, is that the clear_pte_table() is now
called after pgtable_page_ctor() and the addition
Replace __get_free_page() and alloc_pages() calls with the generic
__pte_alloc_one_kernel() and __pte_alloc_one().
There is no functional change for the kernel PTE allocation.
The difference for the user PTEs, is that the clear_pte_table() is now
called after pgtable_page_ctor() and the addition
um allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The pte_free() and pte_free_kernel() versions are identical
The csky implementation pte_alloc_one(), pte_free_kernel() and pte_free()
is identical to the generic except of lack of __GFP_ACCOUNT for the user
PTEs allocation.
Switch csky to use generic version of these functions.
The csky implementation of pte_alloc_one_kernel() is not replaced because
it
MIPS allocates kernel PTE pages with
__get_free_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER)
and user PTE pages with
pte = alloc_pages(GFP_KERNEL, PTE_ORDER)
and then uses clear_highpage(pte) to zero out the allocated page for the
user page tables.
The PTE_ORDER is hardwired to
Enable SPARSEMEM support on alpha and deprecate DISCONTIGMEM.
The required changes are mostly around moving duplicated definitions of
page access and address conversion macros to a common place and making sure
they are available for all memory models.
The DISCONTINGMEM support is marked as
Hi Mike,
Mike Rapoport 於 2019年5月2日 週四 下午11:30寫道：
>
> The nds32 implementation of pte_alloc_one_kernel() differs from the generic
> in the use of __GFP_RETRY_MAYFAIL flag, which is removed after the
> conversion.
>
> The nds32 version of pte_alloc_one() missed the call to pgtable_page_ctor()
>
On Thu, 02 May 2019 08:28:40 PDT (-0700), r...@linux.ibm.com wrote:
The only difference between the generic and RISC-V implementation of PTE
allocation is the usage of __GFP_RETRY_MAYFAIL for both kernel and user
PTEs and the absence of __GFP_ACCOUNT for the user PTEs.
The conversion to the
On Thu, May 02, 2019 at 06:56:07PM +0200, Christophe Leroy wrote:
>
>
> Le 02/05/2019 à 17:28, Mike Rapoport a écrit :
> >The 64-bit book-E powerpc implements pte_alloc_one(),
> >pte_alloc_one_kernel(), pte_free_kernel() and pte_free() the same way as
> >the generic version.
>
> Will soon be
On Fri, May 03, 2019 at 11:05:09AM +0100, Mark Rutland wrote:
> Hi,
>
> On Thu, May 02, 2019 at 06:28:31PM +0300, Mike Rapoport wrote:
> > The PTE allocations in arm64 are identical to the generic ones modulo the
> > GFP flags.
> >
> > Using the generic pte_alloc_one() functions ensures that the
On Thu, May 02, 2019 at 07:09:47PM +, Paul Burton wrote:
> Hi Mike,
>
> On Thu, May 02, 2019 at 06:28:35PM +0300, Mike Rapoport wrote:
> > MIPS allocates kernel PTE pages with
> >
> > __get_free_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER)
> >
> > and user PTE pages with
> >
> >
On Thu, May 02, 2019 at 07:03:11PM +, Paul Burton wrote:
> Hi Mike,
>
> On Thu, May 02, 2019 at 06:28:28PM +0300, Mike Rapoport wrote:
> > +/**
> > + * pte_free_kernel - free PTE-level user page table page
> > + * @mm: the mm_struct of the current context
> > + * @pte_page: the `struct page`
My name is Gavin. I want to get to know you better, if I may be so bold. I
consider myself an honest man, and I am currently looking for a relationship in
which I feel loved. Please tell me more about yourself, if you don't mind.
Gavin.
On Sat, May 04, 2019 at 12:03:48AM +0800, Guo Ren wrote:
> Hi Mike,
>
> Acked-by: Guo Ren
>
> On Thu, May 02, 2019 at 06:28:32PM +0300, Mike Rapoport wrote:
> > The csky implementation pte_alloc_one(), pte_free_kernel() and pte_free()
> > is identical to the generic except of lack of
On 02/05/2019 16:28, Mike Rapoport wrote:
um allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The pte_free()
Hi,
On Thu, May 02, 2019 at 06:28:31PM +0300, Mike Rapoport wrote:
> The PTE allocations in arm64 are identical to the generic ones modulo the
> GFP flags.
>
> Using the generic pte_alloc_one() functions ensures that the user page
> tables are allocated with __GFP_ACCOUNT set.
>
> The arm64
Hi Mike,
On Thu, May 02, 2019 at 06:28:35PM +0300, Mike Rapoport wrote:
> MIPS allocates kernel PTE pages with
>
> __get_free_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER)
>
> and user PTE pages with
>
> alloc_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER)
That bit isn't quite true - we
Hi Mike,
On Thu, May 02, 2019 at 06:28:28PM +0300, Mike Rapoport wrote:
> +/**
> + * pte_free_kernel - free PTE-level user page table page
> + * @mm: the mm_struct of the current context
> + * @pte_page: the `struct page` representing the page table
> + */
> +static inline void pte_free(struct
Le 02/05/2019 à 17:28, Mike Rapoport a écrit :
The 64-bit book-E powerpc implements pte_alloc_one(),
pte_alloc_one_kernel(), pte_free_kernel() and pte_free() the same way as
the generic version.
Will soon be converted to the same as the 3 other PPC subarches, see
My name is Ms Ella Golan, I'm the Chief Executive Officer (C.P.A) of the First
International Bank of Israel (FIBI).
I'm getting in touch with you in regards to a very important and urgent matter.
Kindly respond back at your earliest convenience so
I can provide you the details.
Faithfully,
Ms
Replace __get_free_page() and alloc_pages() calls with the generic
__pte_alloc_one_kernel() and __pte_alloc_one().
There is no functional change for the kernel PTE allocation.
The difference for the user PTEs, is that the clear_pte_table() is now
called after pgtable_page_ctor() and the addition
The csky implementation pte_alloc_one(), pte_free_kernel() and pte_free()
is identical to the generic except of lack of __GFP_ACCOUNT for the user
PTEs allocation.
Switch csky to use generic version of these functions.
The csky implementation of pte_alloc_one_kernel() is not replaced because
it
The PTE allocations in arm64 are identical to the generic ones modulo the
GFP flags.
Using the generic pte_alloc_one() functions ensures that the user page
tables are allocated with __GFP_ACCOUNT set.
The arm64 definition of PGALLOC_GFP is removed and replaced with
GFP_PGTABLE_USER for
MIPS allocates kernel PTE pages with
__get_free_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER)
and user PTE pages with
alloc_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER)
The PTE_ORDER is hardwired to zero, which makes MIPS implementation almost
identical to the generic one.
Switch
The sun3 MMU variant of m68k uses GFP_KERNEL to allocate a PTE page and
then memset(0) or clear_highpage() to clear it.
This is equivalent to allocating the page with GFP_KERNEL | __GFP_ZERO,
which allows replacing sun3 implementation of pte_alloc_one() and
pte_alloc_one_kernel() with the generic
The nds32 implementation of pte_alloc_one_kernel() differs from the generic
in the use of __GFP_RETRY_MAYFAIL flag, which is removed after the
conversion.
The nds32 version of pte_alloc_one() missed the call to pgtable_page_ctor()
and also used __GFP_RETRY_MAYFAIL. Switching it to use generic
nios2 allocates kernel PTE pages with
__get_free_pages(GFP_KERNEL | __GFP_ZERO, PTE_ORDER);
and user page tables with
pte = alloc_pages(GFP_KERNEL, PTE_ORDER);
if (pte)
clear_highpage();
The PTE_ORDER is hardwired to zero, which makes nios2
The 64-bit book-E powerpc implements pte_alloc_one(),
pte_alloc_one_kernel(), pte_free_kernel() and pte_free() the same way as
the generic version.
Switch it to the generic version that does exactly the same thing.
Signed-off-by: Mike Rapoport
---
arch/powerpc/include/asm/nohash/64/pgalloc.h |
Replace __get_free_page() and alloc_pages() calls with the generic
__pte_alloc_one_kernel() and __pte_alloc_one().
There is no functional change for the kernel PTE allocation.
The difference for the user PTEs, is that the clear_pte_table() is now
called after pgtable_page_ctor() and the addition
um allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The pte_free() and pte_free_kernel() versions are identical
parisc allocates PTE pages with __get_free_page() and uses
GFP_KERNEL | __GFP_ZERO for the allocations.
Switch it to the generic version that does exactly the same thing for the
kernel page tables and adds __GFP_ACCOUNT for the user PTEs.
The pte_free_kernel() and pte_free() versions on are
Hi,
I've tried to trim down the recipients list, but it's still quite long, so
sorry for the spam.
Many architectures have similar, if not identical implementation of
pte_alloc_one_kernel(), pte_alloc_one(), pte_free_kernel() and pte_free().
A while ago Anshuman suggested to introduce a common
Hello sirs,
We are interested in some of your product.
pls send catalog asap. Thanks
Danielle
JAPAN Sales Dept.
3.16.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Sergei Trofimovich
commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This
Dear Friend,
I am Ms Safi Kabore work with the department of Audit and accounting manager
here in the Bank,
There is this fund that was keep in my custody years ago,please i need your
assistance for the transferring of thIs fund to your bank account for both of
us benefit for life time
The 'timeval' and 'timespec' data structures used for socket timestamps
are going to be redefined in user space based on 64-bit time_t in future
versions of the C library to deal with the y2038 overflow problem,
which breaks the ABI definition.
Unlike many modern ioctl commands, SIOCGSTAMP and
On Mon, Apr 15, 2019 at 04:22:57PM +0200, Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
> the
Hi Linus,
I'm Jon, and I just bought my first Alpha. What can I say, I was late to
the party, and I probably need to get out more. Actually, I wanted it
for its memory consistency model, or (some would say) lack thereof.
On 3/11/19 3:03 PM, Linus Torvalds wrote:
> On Mon, Mar 11, 2019 at 11:08
Hi Arnd,
On Mon, Apr 15, 2019 at 04:22:57PM +0200, Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
Add the io_uring and pidfd_send_signal system calls to all architectures.
These system calls are designed to handle both native and compat tasks,
so all entries are the same across architectures, only arm-compat and
the generic tale still use an old format.
Acked-by: Michael Ellerman (powerpc)
Hi dear,
I am still waiting for your Email response, you did receive my first
email to you
Respectfully Yours,
Mrs Katie Huggins
On Fri, 5 Apr 2019, Maciej W. Rozycki wrote:
> On Fri, 5 Apr 2019, Mikulas Patocka wrote:
>
> > > > I did some more testing and it turns out that mb() is not entirely
> > > > sufficient to prevent the boot hang. mb()'s latecy varies, sometimes it
> > > > is
> > > > sufficient, sometimes
On 4/5/2019 2:28 PM, Maciej W. Rozycki wrote:
You basically can't remove the mb() after __ioread() and before
__iowrite() unless your architecture guarantees IO vs. memory ordering.
I never suggested that; please check my example too.
Sounds good. Sorry for the noise.
I just wanted to make
On 4/5/2019 1:29 PM, Maciej W. Rozycki wrote:
Obviously you do need that `mb' before `__ioread' in the second case,
just like in the first one, because otherwise the read bus access issued
by `__ioread' can be reordered ahead of the write bus access issued by the
preceding `__iowrite'.
On Fri, 5 Apr 2019, Mikulas Patocka wrote:
> > > I did some more testing and it turns out that mb() is not entirely
> > > sufficient to prevent the boot hang. mb()'s latecy varies, sometimes it
> > > is
> > > sufficient, sometimes not.
> > >
> > > So, I submit this patch that adds 1us delay
Dear Friend,
I am Ms Safi Kabore work with the department of Audit and accounting manager
here in the Bank,
There is this fund that was keep in my custody years ago,please i need your
assistance for the transferring of thIs fund to your bank account for both of
us benefit for life time
Alpha incorrectly reports "0070-0080 : rtc" in /proc/ioports.
Fix this, so that it is "0070-007f".
Signed-off-by: Mikulas Patocka
---
arch/alpha/kernel/setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-stable/arch/alpha/kernel/setup.c
On Thu, 4 Apr 2019, Linus Torvalds wrote:
> On Wed, Apr 3, 2019 at 9:28 AM Mikulas Patocka wrote:
> >
> > So, I submit this patch that adds 1us delay between any I/O accesses
> > directed at the ISA bus. This patch makes my machine boot. 1us seems to be
> > minimal acceptable value, with
On Thu, 4 Apr 2019, Maciej W. Rozycki wrote:
> On Wed, 3 Apr 2019, Mikulas Patocka wrote:
>
> > I did some more testing and it turns out that mb() is not entirely
> > sufficient to prevent the boot hang. mb()'s latecy varies, sometimes it is
> > sufficient, sometimes not.
> >
> > So, I
On Wed, Apr 3, 2019 at 9:28 AM Mikulas Patocka wrote:
>
> So, I submit this patch that adds 1us delay between any I/O accesses
> directed at the ISA bus. This patch makes my machine boot. 1us seems to be
> minimal acceptable value, with 800ns I still get hangs.
I don't think this is right.
The
On Wed, 3 Apr 2019, Mikulas Patocka wrote:
> > > > Well, actually `iowriteX' is generic and for MMIO you have `writeX'.
> > > > See lib/iomap.c, the comment at the top and e.g. `iowrite8' there for
> > > > an
> > > > actual proof. Alpha may have an oddball implementation, but there you
> >
Jens Axboe writes:
> On 4/3/19 5:11 AM, Will Deacon wrote:
>> On Wed, Apr 03, 2019 at 01:47:50PM +1100, Michael Ellerman wrote:
>>> Arnd Bergmann writes:
diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
b/arch/powerpc/kernel/syscalls/syscall.tbl
index
On Wed, 20 Feb 2019, Maciej W. Rozycki wrote:
> On Wed, 20 Feb 2019, Mikulas Patocka wrote:
>
> > > Well, actually `iowriteX' is generic and for MMIO you have `writeX'.
> > > See lib/iomap.c, the comment at the top and e.g. `iowrite8' there for an
> > > actual proof. Alpha may have an
On 4/3/19 9:49 AM, Will Deacon wrote:
> On Wed, Apr 03, 2019 at 09:39:52AM -0600, Jens Axboe wrote:
>> On 4/3/19 9:19 AM, Will Deacon wrote:
>>> On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
On 4/3/19 5:11 AM, Will Deacon wrote:
> will@autoplooker:~/liburing/test$
On Wed, Apr 03, 2019 at 09:39:52AM -0600, Jens Axboe wrote:
> On 4/3/19 9:19 AM, Will Deacon wrote:
> > On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
> >> On 4/3/19 5:11 AM, Will Deacon wrote:
> >>> will@autoplooker:~/liburing/test$ ./io_uring_register
> >>> RELIMIT_MEMLOCK:
On 4/3/19 9:19 AM, Will Deacon wrote:
> Hi Jens,
>
> On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
>> On 4/3/19 5:11 AM, Will Deacon wrote:
>>> will@autoplooker:~/liburing/test$ ./io_uring_register
>>> RELIMIT_MEMLOCK: 67108864 (67108864)
>>> [ 35.477875] Unable to handle kernel
Hi Jens,
On Wed, Apr 03, 2019 at 07:49:26AM -0600, Jens Axboe wrote:
> On 4/3/19 5:11 AM, Will Deacon wrote:
> > will@autoplooker:~/liburing/test$ ./io_uring_register
> > RELIMIT_MEMLOCK: 67108864 (67108864)
> > [ 35.477875] Unable to handle kernel NULL pointer dereference at virtual
> >
On 4/3/19 5:11 AM, Will Deacon wrote:
> Hi Michael,
>
> On Wed, Apr 03, 2019 at 01:47:50PM +1100, Michael Ellerman wrote:
>> Arnd Bergmann writes:
>>> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
>>> b/arch/powerpc/kernel/syscalls/syscall.tbl
>>> index b18abb0c3dae..00f5a63c8d9a 100644
Hi Michael,
On Wed, Apr 03, 2019 at 01:47:50PM +1100, Michael Ellerman wrote:
> Arnd Bergmann writes:
> > diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
> > b/arch/powerpc/kernel/syscalls/syscall.tbl
> > index b18abb0c3dae..00f5a63c8d9a 100644
> > ---
This is to inform you that Turkey Financier here in Turkey offers loan to
anyone who might be in need of a loan for any financial concern. Should you be
interested in applying for a business or personal loan, you are required to
send an enquiry to us for further proceedings. We offer loan
Arnd Bergmann writes:
> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
> b/arch/powerpc/kernel/syscalls/syscall.tbl
> index b18abb0c3dae..00f5a63c8d9a 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -505,3 +505,7 @@
> 421 32
Arnd Bergmann writes:
> On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman wrote:
>>
>> Arnd Bergmann writes:
>> > Add the io_uring and pidfd_send_signal system calls to all architectures.
>> >
>> > These system calls are designed to handle both native and compat tasks,
>> > so all entries are
On Mon, Mar 25, 2019 at 3:48 PM Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
> the generic tale
On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman wrote:
>
> Arnd Bergmann writes:
> > Add the io_uring and pidfd_send_signal system calls to all architectures.
> >
> > These system calls are designed to handle both native and compat tasks,
> > so all entries are the same across architectures,
Arnd Bergmann writes:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
> the generic tale still use an old format.
>
>
On Sat, Mar 30, 2019 at 10:30:23AM +, George Spelvin wrote:
> For s390, that was added on 24 March 2017 by
> https://gcc.gnu.org/viewcvs/gcc?view=revision=246457
> which is part of GCC 7.
>
> It also only applies to TARGET_ARCH12, which I am guessing
> corresponds to
On Sat, Mar 30, 2019 at 11:28:21AM +, George Spelvin wrote:
> >> I like that the MIPS code leaves the high half of the product in
> >> the hi register until it tests the low half; I wish PowerPC would
> >> similarly move the mulhdu *after* the loop,
>
> > The MIPS code has the multiplication
On Sat, Mar 30, 2019 at 09:00:15AM +1300, Michael Cree wrote:
> It does move the umulh inside the loop but that seems sensible since
> the use of unlikely() implies that the loop is unlikely to be taken
> so on average it would be a good bet to start the calculation of
> umulh earlier since it has
I've been tracking down when "umulditi3" support was added to various
gcc platforms. So far, I've found:
ia64: 2005-07-28, gcc 4.1.0
https://gcc.gnu.org/viewcvs/gcc?view=revision=102463
mips: 2008-06-09, gcc 4.4.0
https://gcc.gnu.org/viewcvs/gcc?view=revision=136600
alpha: 2013-02-01, gcc
General update:
I've since found the reason for the GCC version check.
It's not *broken* support (apologies for impugning GCC),
but *inefficient* support via a muditi3 helper function.
The version check is the version which added in-line code generation.
For example, s390 support was added in
On Sat, 30 Mar 2019 at 09:43:47 +0100, Heiko Carstens wrote:
> It hasn't been enabled on s390 simply because at least I wasn't aware
> of this config option. Feel free to send a patch, otherwise I will
> enable this. Whatever you prefer.
>
> Thanks for pointing this out!
Here's a draft patch,
On Mon, Mar 25, 2019 at 03:47:37PM +0100, Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
> the
On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote:
> (Cross-posted in case there are generic issues; please trim if
> discussion wanders into single-architecture details.)
>
> I was working on some scaling code that can benefit from 64x64->128-bit
> multiplies. GCC supports an
Hi!
On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote:
> I was working on some scaling code that can benefit from 64x64->128-bit
> multiplies. GCC supports an __int128 type on processors with hardware
> support (including z/Arch and MIPS64), but the support was broken on
> early
On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote:
> I was working on some scaling code that can benefit from 64x64->128-bit
> multiplies. GCC supports an __int128 type on processors with hardware
> support (including z/Arch and MIPS64), but the support was broken on
> early
(Cross-posted in case there are generic issues; please trim if
discussion wanders into single-architecture details.)
I was working on some scaling code that can benefit from 64x64->128-bit
multiplies. GCC supports an __int128 type on processors with hardware
support (including z/Arch and
Hello this is Mr Wong again from hongkong,Can we send the Swift as discuss best
regards.
Mr Wong Cheng
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
I have a business Proposal that will be of benefit to the both of us.Kindly
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
On Mon, Mar 25, 2019 at 6:37 PM Paul Burton wrote:
> On Mon, Mar 25, 2019 at 03:47:37PM +0100, Arnd Bergmann wrote:
> > Add the io_uring and pidfd_send_signal system calls to all architectures.
> >
> > These system calls are designed to handle both native and compat tasks,
> > so all entries are
Hi Arnd,
On Mon, Mar 25, 2019 at 03:47:37PM +0100, Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
Hi,
Could you share the microbenchmark you are using ?
I'd like to test the series on powerpc.
Thanks
Christophe
Le 22/03/2019 à 15:30, Waiman Long a écrit :
Modify __down_read_trylock() to optimize for an unlocked rwsem and make
it generate slightly better code.
Before this patch,
Add the io_uring and pidfd_send_signal system calls to all architectures.
These system calls are designed to handle both native and compat tasks,
so all entries are the same across architectures, only arm-compat and
the generic tale still use an old format.
Signed-off-by: Arnd Bergmann
---
Hello,
My name is Miss Eden,i saw your profile and i love it,i think we can make it
together,please i will like you to email me back through my email thus;so that
i will send you my picture.so that we will discuss more about my interest,I
will be waiting to receive your lovely reply soon
On 03/22/2019 03:30 PM, Davidlohr Bueso wrote:
> On Fri, 22 Mar 2019, Linus Torvalds wrote:
>> Some of them _might_ be performance-critical. There's the one on
>> mmap_sem in the fault handling path, for example. And yes, I'd expect
>> the normal case to very much be "no other readers or writers"
On Fri, 22 Mar 2019, Linus Torvalds wrote:
Some of them _might_ be performance-critical. There's the one on
mmap_sem in the fault handling path, for example. And yes, I'd expect
the normal case to very much be "no other readers or writers" for that
one.
Yeah, the mmap_sem case in the fault
On 03/22/2019 01:25 PM, Russell King - ARM Linux admin wrote:
> On Fri, Mar 22, 2019 at 10:30:08AM -0400, Waiman Long wrote:
>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>> it generate slightly better code.
>>
>> Before this patch, down_read_trylock:
>>
>>
On Fri, Mar 22, 2019 at 10:30:08AM -0400, Waiman Long wrote:
> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> it generate slightly better code.
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>:
601 - 700 of 2609 matches
Mail list logo
