On Mon, Jun 26, 2023, at 10:48 AM, Song Liu wrote:
> On Mon, Jun 26, 2023 at 5:31 AM Mark Rutland wrote:
>>
> [...]
>> >
>> > So the idea was that jit_text_alloc() will have a cache of large pages
>> > mapped ROX, will allocate memory from those caches and there will be
>> > jit_update() that u
On Sun, Jun 25, 2023, at 9:14 AM, Mike Rapoport wrote:
> On Mon, Jun 19, 2023 at 10:09:02AM -0700, Andy Lutomirski wrote:
>>
>> On Sun, Jun 18, 2023, at 1:00 AM, Mike Rapoport wrote:
>> > On Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote:
>> >&
On Mon, Jun 19, 2023, at 1:18 PM, Nadav Amit wrote:
>> On Jun 19, 2023, at 10:09 AM, Andy Lutomirski wrote:
>>
>> But jit_text_alloc() can't do this, because the order of operations doesn't
>> match. With jit_text_alloc(), the executable mapping shows up be
On Sun, Jun 18, 2023, at 1:00 AM, Mike Rapoport wrote:
> On Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote:
>> On Fri, Jun 16, 2023, at 1:50 AM, Mike Rapoport wrote:
>> > From: "Mike Rapoport (IBM)"
>> >
>> > module_alloc() is used ev
On Fri, Jun 16, 2023, at 1:50 AM, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> module_alloc() is used everywhere as a mean to allocate memory for code.
>
> Beside being semantically wrong, this unnecessarily ties all subsystems
> that need to allocate code, such as ftrace, kprobes and BP
On Fri, Feb 18, 2022 at 1:30 AM David Laight wrote:
>
> From: Andy Lutomirski
> > Sent: 17 February 2022 19:15
> ...
> > This isn't actually optimal. On x86, TASK_SIZE_MAX is a bizarre
> > constant that has a very specific value to work around a bug^Wdesign
On Wed, Feb 16, 2022 at 5:19 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> There are many different ways that access_ok() is defined across
> architectures, but in the end, they all just compare against the
> user_addr_max() value or they accept anything.
>
> Provide one definition that wor
m64
Fixes: 70216e18e519 ("membarrier: Provide core serializing command,
*_SYNC_CORE")
Signed-off-by: Andy Lutomirski
---
.../membarrier-sync-core/arch-support.txt | 69 ++-
arch/arm/include/asm/membarrier.h | 21 ++
arch/arm64/include/asm/membarrier.h
l Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Nicholas Piggin
Cc: Mathieu Desnoyers
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/powerpc/include/asm/membarrier.h | 24
arch/powerpc/mm/mmu_context.c |
On Fri, Jun 18, 2021, at 11:02 PM, Nicholas Piggin wrote:
> Excerpts from Mathieu Desnoyers's message of June 19, 2021 6:09 am:
> > - On Jun 18, 2021, at 3:58 PM, Andy Lutomirski l...@kernel.org wrote:
> >
> >> On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoy
On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers wrote:
> - On Jun 17, 2021, at 8:12 PM, Andy Lutomirski l...@kernel.org wrote:
>
> > On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
> >
> >> Please change back this #ifndef / #else / #endif within function for
On 6/17/21 8:16 AM, Mathieu Desnoyers wrote:
> - On Jun 15, 2021, at 11:21 PM, Andy Lutomirski l...@kernel.org wrote:
>
> [...]
>
>> +# An architecture that wants to support
>> +# MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE needs to define precisely what
>>
On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
> Please change back this #ifndef / #else / #endif within function for
>
> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE)) {
> ...
> } else {
> ...
> }
>
> I don't think mixing up preprocessor and code logic makes it more readable.
I agree
On Wed, Jun 16, 2021, at 3:20 AM, Will Deacon wrote:
>
> For the arm64 bits (docs and asm/sync_core.h):
>
> Acked-by: Will Deacon
>
Thanks.
Per Nick's suggestion, I renamed the header to membarrier.h. Unless I hear
otherwise, I'll keep the ack.
> Will
>
On Wed, Jun 16, 2021, at 11:52 AM, Andy Lutomirski wrote:
> On 6/15/21 9:45 PM, Nicholas Piggin wrote:
> > Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm:
> >> The old sync_core_before_usermode() comments suggested that a
> >> non-icache
On 6/15/21 9:45 PM, Nicholas Piggin wrote:
> Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm:
>> The old sync_core_before_usermode() comments suggested that a
>> non-icache-syncing
>> return-to-usermode instruction is x86-specific and that all other
>> architectures automatically
Desnoyers
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/powerpc/include/asm/membarrier.h | 27 ---
arch/powerpc/mm/mmu_context.c | 2 --
2 files changed, 29 deletions(-)
delete mode 100644 arch/powerpc/include/asm/membarrier.h
diff --git a/arch/power
l Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Nicholas Piggin
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: Mathieu Desnoyers
Cc: Nicholas Piggin
Cc: Peter Zijlstra
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
Fixes: 70216e18e519 ("membarrier: Prov
On 6/14/21 5:55 PM, Nicholas Piggin wrote:
> Excerpts from Andy Lutomirski's message of June 15, 2021 2:20 am:
>> Replying to several emails at once...
>>
>
> So the only documentation relating to the current active_mm value or
> refcounting is that it may not match what the x86 specific code is
Replying to several emails at once...
On 6/13/21 10:21 PM, Nicholas Piggin wrote:
> Excerpts from Nicholas Piggin's message of June 14, 2021 2:47 pm:
>> Excerpts from Nicholas Piggin's message of June 14, 2021 2:14 pm:
>>> Excerpts from Andy Lutomirski's message of June 14, 2021 1:52 pm:
On
On 6/13/21 5:45 PM, Nicholas Piggin wrote:
> Excerpts from Andy Lutomirski's message of June 9, 2021 2:20 am:
>> On 6/4/21 6:42 PM, Nicholas Piggin wrote:
>>> Add CONFIG_MMU_TLB_REFCOUNT which enables refcounting of the lazy tlb mm
>>> when it is context switched. This can be disabled by architectu
On 6/4/21 6:42 PM, Nicholas Piggin wrote:
> Add CONFIG_MMU_TLB_REFCOUNT which enables refcounting of the lazy tlb mm
> when it is context switched. This can be disabled by architectures that
> don't require this refcounting if they clean up lazy tlb mms when the
> last refcount is dropped. Currentl
On 6/4/21 9:54 AM, Andy Lutomirski wrote:
> On 5/31/21 11:22 PM, Nicholas Piggin wrote:
>> There haven't been objections to the series since last posting, this
>> is just a rebase and tidies up a few comments minor patch rearranging.
>>
>
> I continue to object t
On 5/31/21 11:22 PM, Nicholas Piggin wrote:
> There haven't been objections to the series since last posting, this
> is just a rebase and tidies up a few comments minor patch rearranging.
>
I continue to object to having too many modes. I like my more generic
improvements better. Let me try to
On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>
> From: Nadav Amit
>
> There are currently (at least?) 5 different TLB batching schemes in the
> kernel:
>
> 1. Using mmu_gather (e.g., zap_page_range()).
>
> 2. Using {inc|dec}_tlb_flush_pending() to inform other threads on the
>ongoing def
> On Jan 5, 2021, at 5:26 AM, Will Deacon wrote:
>
> Hi Andy,
>
> Sorry for the slow reply, I was socially distanced from my keyboard.
>
>> On Mon, Dec 28, 2020 at 04:36:11PM -0800, Andy Lutomirski wrote:
>> On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin w
On Mon, Dec 28, 2020 at 4:36 PM Nicholas Piggin wrote:
>
> Excerpts from Andy Lutomirski's message of December 29, 2020 7:06 am:
> > On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
> > wrote:
> >>
> >> - On Dec 28, 2020, at 2:44 PM, Andy Lutomir
On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin wrote:
>
> Excerpts from Andy Lutomirski's message of December 28, 2020 4:28 am:
> > The old sync_core_before_usermode() comments said that a non-icache-syncing
> > return-to-usermode instruction is x86-specific and that all other
> > architectures a
On Mon, Dec 28, 2020 at 1:09 PM Mathieu Desnoyers
wrote:
>
> - On Dec 27, 2020, at 4:36 PM, Andy Lutomirski l...@kernel.org wrote:
>
> [...]
>
> >> You seem to have noticed odd cases on arm64 where this guarantee does not
> >> match reality. Where exactly
On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers
wrote:
>
> - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote:
>
> > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
> > wrote:
> >>
> >> On Mon, Dec 28, 20
On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
wrote:
>
> On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> > After chatting with rmk about this (but without claiming that any of
> > this is his opinion), based on the manpage, I think membarrier()
> > currently doesn't
On Mon, Dec 28, 2020 at 10:30 AM Jann Horn wrote:
>
> On Mon, Dec 28, 2020 at 6:14 PM Andy Lutomirski wrote:
> > On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wr
On Mon, Dec 28, 2020 at 9:23 AM Russell King - ARM Linux admin
wrote:
>
> On Mon, Dec 28, 2020 at 09:14:23AM -0800, Andy Lutomirski wrote:
> > On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Sun, Dec 27, 2020 at 01:
On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin
wrote:
>
> On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote:
> > On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers
> > wrote:
> > >
> > > ----- On Dec 27, 2020, at 1:28 PM, A
On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers
wrote:
>
> - On Dec 27, 2020, at 1:28 PM, Andy Lutomirski l...@kernel.org wrote:
>
> >
> > I admit that I'm rather surprised that the code worked at all on arm64,
> > and I'm suspicious that it has never
70216e18e519 ("membarrier: Provide core serializing command,
*_SYNC_CORE")
Signed-off-by: Andy Lutomirski
---
Hi arm64 and powerpc people-
This is part of a series here:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/fixes
Before I send out the whole series,
> On Dec 5, 2020, at 7:59 PM, Nicholas Piggin wrote:
>
> I'm still going to persue shoot-lazies for the merge window. As you
> see it's about a dozen lines and a if (IS_ENABLED(... in core code.
> Your change is common code, but a significant complexity (which
> affects all archs) so needs a lot
On Sat, Dec 5, 2020 at 3:15 PM Nicholas Piggin wrote:
>
> Excerpts from Andy Lutomirski's message of December 6, 2020 2:11 am:
> >
> If an mm was lazy tlb for a kernel thread and then it becomes unlazy,
> and if switch_mm is serialising but return to user is not, then you
> need a serialising ins
> On Dec 5, 2020, at 12:00 AM, Nicholas Piggin wrote:
>
>
> I disagree. Until now nobody following it noticed that the mm gets
> un-lazied in other cases, because that was not too clear from the
> code (only indirectly using non-standard terminology in the arch
> support document).
> In other
> On Dec 3, 2020, at 11:54 PM, Nicholas Piggin wrote:
>
> Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm:
>> This is a mockup. It's designed to illustrate the algorithm and how the
>> code might be structured. There are several things blatantly wrong with
>> it:
>>
>>
mask() not being reliable.
Signed-off-by: Andy Lutomirski
---
kernel/fork.c| 4 ++
kernel/sched/core.c | 128 +--
kernel/sched/sched.h | 11 +++-
3 files changed, 126 insertions(+), 17 deletions(-)
diff --git a/kernel/fork.c b/kernel/fo
d it's not clear to me
that these barriers are actually present in all paths through the
code. So I think this change makes the code more comprehensible and
has no effect on the code's correctness, but I'm not at all convinced
that the code is correct.
Signed-off-by: Andy Lutomirsk
ly me) needs to make
sure we don't need some extra barriers.
power: Similar to x86.
s390x: Should be essentially the same as arm64.
Other arches: I don't know. Further research is required.
What do you all think?
Andy Lutomirski (2):
[NEEDS HELP] x86/mm: Handle unlazying membarrie
> On Dec 3, 2020, at 2:13 PM, Nicholas Piggin wrote:
>
> Excerpts from Peter Zijlstra's message of December 3, 2020 6:44 pm:
>>> On Wed, Dec 02, 2020 at 09:25:51PM -0800, Andy Lutomirski wrote:
>>>
>>> power: same as ARM, except that the loop may b
> On Dec 3, 2020, at 9:09 AM, Alexander Gordeev wrote:
>
> On Mon, Nov 30, 2020 at 10:31:51AM -0800, Andy Lutomirski wrote:
>> other arch folk: there's some background here:
>
>>
>> power: Ridiculously complicated, seems to vary by system and k
tch as is. That
being said, getting rid of the active_mm refcounting shouldn't be
so hard, since x86 (in this tree) no longer uses active_mm at all.
I should contemplate whether the calling CPU is special in
arch_fixup_lazy_mm_refs(). On a very very quick think, it's not, but
it
us the scheduler code provides the barriers
that membarrier needs is quite complicated, and it's not clear to me
that the code is even correct. At the very least I'm pretty sure that
the x86 comments are misleading. With your patches, someone trying to
audit the code would have to follow cor
@mail.gmail.com
>>
>>> On Sun, Nov 29, 2020 at 12:16 PM Andy Lutomirski wrote:
>>>
>>> On Sat, Nov 28, 2020 at 7:54 PM Andy Lutomirski wrote:
>>>>
>>>> On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote:
>>>>>
>&
> On Dec 2, 2020, at 6:20 AM, Peter Zijlstra wrote:
>
> On Sun, Nov 29, 2020 at 02:01:39AM +1000, Nicholas Piggin wrote:
>> + * - A delayed freeing and RCU-like quiescing sequence based on
>> + * mm switching to avoid IPIs completely.
>
> That one's interesting too. so basic
On Tue, Dec 1, 2020 at 1:28 PM Will Deacon wrote:
>
> On Mon, Nov 30, 2020 at 10:31:51AM -0800, Andy Lutomirski wrote:
> > other arch folk: there's some background here:
> >
> > https://lkml.kernel.org/r/calcetrvxube8lfnn-qs+dzroqaiw+sfug1j047ybyv31sat...@mail.gma
other arch folk: there's some background here:
https://lkml.kernel.org/r/calcetrvxube8lfnn-qs+dzroqaiw+sfug1j047ybyv31sat...@mail.gmail.com
On Sun, Nov 29, 2020 at 12:16 PM Andy Lutomirski wrote:
>
> On Sat, Nov 28, 2020 at 7:54 PM Andy Lutomirski wrote:
> >
> > On Sat,
On Sat, Nov 28, 2020 at 7:54 PM Andy Lutomirski wrote:
>
> On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote:
> >
> > On big systems, the mm refcount can become highly contented when doing
> > a lot of context switching with threaded applications (particularly
> &
On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote:
>
> On big systems, the mm refcount can become highly contented when doing
> a lot of context switching with threaded applications (particularly
> switching between the idle thread and an application thread).
>
> Abandoning lazy tlb slows swit
On Sat, Nov 28, 2020 at 8:01 AM Nicholas Piggin wrote:
>
> This is called at points where a lazy mm is switched away or made not
> lazy (by its owner switching back).
>
> Signed-off-by: Nicholas Piggin
> ---
> arch/arm/mach-rpc/ecard.c| 1 +
> arch/powerpc/mm/book3s64/radix_tlb.c |
On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote:
>
> NOMMU systems could easily go without this and save a bit of code
> and the refcount atomics, because their mm switch is a no-op. I
> haven't flipped them over because haven't audited all arch code to
> convert over to using the _lazy_tlb
On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote:
>
> And get rid of the generic sync_core_before_usermode facility. This is
> functionally a no-op in the core scheduler code, but it also catches
>
> This helper is the wrong way around I think. The idea that membarrier
> state requires a core
> On Sep 22, 2020, at 2:01 AM, Arnd Bergmann wrote:
>
> On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov
> wrote:
>>> On 22/09/2020 10:23, Arnd Bergmann wrote:
>>> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov
>>> wrote:
>>>> On 22/09/2
On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov wrote:
>
>
>
> On 22/09/2020 02:51, Andy Lutomirski wrote:
> > On Mon, Sep 21, 2020 at 9:15 AM Pavel Begunkov
> > wrote:
> >>
> >> On 21/09/2020 19:10, Pavel Begunkov wrote:
> >>> On 20/09/2020
On Mon, Sep 21, 2020 at 9:15 AM Pavel Begunkov wrote:
>
> On 21/09/2020 19:10, Pavel Begunkov wrote:
> > On 20/09/2020 01:22, Andy Lutomirski wrote:
> >>
> >>> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote:
> >>>
> >>> On Sat, Sep 1
If you're a 32-bit process, you don't get to use io_uring. Would
> any real users actually care about that?
We could go one step farther and declare that we're done adding *any*
new compat syscalls :)
--
Andy Lutomirski
AMA Capital Management, LLC
On Sun, Sep 20, 2020 at 11:07 AM Al Viro wrote:
>
> On Sun, Sep 20, 2020 at 04:15:10PM +0100, Matthew Wilcox wrote:
> > On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote:
> > > Add a flag to force processing a syscall as a compat syscall. This is
> > > required so that in_compat_s
On Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote:
>
> > > 2) have you counted the syscalls that do and do not need that?
> >
> > No.
>
> Might be illuminating...
>
> > > 3) how m
On Sat, Sep 19, 2020 at 4:24 PM Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:
>
> > > It would not be a win - most of the syscalls don't give a damn
> > > about 32bit vs. 64bit...
> >
> > Any reasonable implementa
> On Sep 19, 2020, at 3:41 PM, Al Viro wrote:
>
> On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
>>
>>>> On Sep 19, 2020, at 3:09 PM, Al Viro wrote:
>>>
>>> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
&
> On Sep 19, 2020, at 3:09 PM, Al Viro wrote:
>
> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>> Said that, why not provide a variant that would take an explicit
>>> "is it compat" argument and use it there?
> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote:
>
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote:
>>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>>> Said that, wh
On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote:
>
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > Said that, why not provide a variant that would take an explicit
> > "is it compat" argument and use it there? And have the normal
> > one pass in_compat_syscall() to that...
On Wed, Sep 2, 2020 at 1:29 AM Thomas Gleixner wrote:
>
> On Tue, Sep 01 2020 at 17:09, Andy Lutomirski wrote:
> > On Tue, Sep 1, 2020 at 4:50 PM Thomas Gleixner wrote:
> >> > I think that they almost work for x86, but not quite as
> >> > indicated by this bug
On Tue, Sep 1, 2020 at 4:50 PM Thomas Gleixner wrote:
>
> On Sun, Aug 30 2020 at 08:52, Andy Lutomirski wrote:
> >> > [RUN]SYSCALL
> >> > [FAIL]Initial args are wrong (nr=29, args=0 0 0 0 0 4289172732)
> >> > [RUN]SYSCALL
> >>
On Sat, Aug 29, 2020 at 9:40 PM Brian Gerst wrote:
>
> On Sat, Aug 29, 2020 at 12:52 PM Andy Lutomirski wrote:
> >
> > Seems to be a recent regression, maybe related to entry/exit work changes.
> >
> > # ./tools/testing/selftests/x86/ptrace_syscall_32
> > [RUN
> On Jul 15, 2020, at 9:15 PM, Nicholas Piggin wrote:
>
> Excerpts from Mathieu Desnoyers's message of July 14, 2020 12:13 am:
>> - On Jul 13, 2020, at 9:47 AM, Nicholas Piggin npig...@gmail.com wrote:
>>
>>> Excerpts from Nicholas Piggin's message of July 13, 2020 2:45 pm:
Excerpts
> On Jul 13, 2020, at 11:31 PM, Nicholas Piggin wrote:
>
> Excerpts from Nicholas Piggin's message of July 14, 2020 3:04 pm:
>> Excerpts from Andy Lutomirski's message of July 14, 2020 4:18 am:
>>>
On Jul 13, 2020, at 9:48 AM, Nicholas Piggin wrote:
Excerpts from Andy Lutom
> On Jul 13, 2020, at 9:48 AM, Nicholas Piggin wrote:
>
> Excerpts from Andy Lutomirski's message of July 14, 2020 1:59 am:
>>> On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin wrote:
>>>
>>> On big systems, the mm refcount can become highly contented when doing
>>> a lot of context switching
On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin wrote:
>
> On big systems, the mm refcount can become highly contented when doing
> a lot of context switching with threaded applications (particularly
> switching between the idle thread and an application thread).
>
> Abandoning lazy tlb slows switc
On Mon, Jul 13, 2020 at 7:13 AM Mathieu Desnoyers
wrote:
>
> - On Jul 13, 2020, at 9:47 AM, Nicholas Piggin npig...@gmail.com wrote:
>
> > Excerpts from Nicholas Piggin's message of July 13, 2020 2:45 pm:
> >> Excerpts from Andy Lutomirski's message of July 11, 2020 3:04 am:
> >>> Also, as it
On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin wrote:
>
> And get rid of the generic sync_core_before_usermode facility.
>
> This helper is the wrong way around I think. The idea that membarrier
> state requires a core sync before returning to user is the easy one
> that does not need hiding behin
> On Jun 15, 2020, at 1:56 PM, Luck, Tony wrote:
>
>
>>
>> Are we planning to keep PASID live once a task has used it once or are we
>> going to swap it lazily? If the latter, a percpu variable might be better.
>
> Current plan is "touch it once and the task owns it until exit(2)"
>
> M
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu wrote:
>
> Hi, Peter,
>
>> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
>>> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>>>
>>> Or do you suggest to add a random new flag in struct thread_info instead
>>> of a TIF f
On Thu, Jan 16, 2020 at 2:35 AM Thomas Gleixner wrote:
>
> static __maybe_unused int
> __cvdso_data_clock_gettime(clockid_t clock, struct __kernel_timespec *ts,
>const struct vdso_data *vd)
> {
> .
> }
>
> static __maybe_unused int
> __cvdso_clock_gettime(cl
On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
> >
> > Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
> > assume the shift is less than 32? That functio
On Thu, Jan 16, 2020 at 12:14 PM Thomas Gleixner wrote:
>
> Christophe Leroy writes:
>
> Can you please adjust the prefix for future patches to lib/vdso: and
> start the sentence after the colon with an uppercase letter?
>
> > On arches like POWERPC, the clock is always the timebase, it
>
> Pleas
On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
wrote:
>
> On powerpc/32, GCC (8.1) generates pretty bad code for the
> ns >>= vd->shift operation taking into account that the
> shift is always < 32 and the upper part of the result is
> likely to be nul. GCC makes reversed assumptions considering
> On Jan 10, 2020, at 10:56 AM, Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
>
>>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
>>> wrote:
>>>
>>> In order to simplify next step which moves fallback call at arch
>>>
On Tue, Dec 24, 2019 at 4:15 AM Andy Lutomirski wrote:
>
>
>
> > On Dec 24, 2019, at 7:53 PM, christophe leroy
> > wrote:
> >
> >
> >
> >> Le 24/12/2019 à 03:27, Andy Lutomirski a écrit :
> >>> On Mon, Dec 23, 2019 at 6
> On Dec 24, 2019, at 7:53 PM, christophe leroy wrote:
>
>
>
>> Le 24/12/2019 à 03:27, Andy Lutomirski a écrit :
>>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
>>> wrote:
>>>
>>> On powerpc, __arch_get_vdso_data() clobbers the
> On Dec 24, 2019, at 7:41 PM, christophe leroy wrote:
>
>
>
>> Le 24/12/2019 à 03:24, Andy Lutomirski a écrit :
>>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
>>> wrote:
>>>
>>> On powerpc, VDSO functions and syscalls canno
> On Dec 24, 2019, at 7:12 PM, christophe leroy wrote:
>
>
>
>> Le 24/12/2019 à 02:58, Andy Lutomirski a écrit :
>>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
>>> wrote:
>>>
>>> READ_ONCE() forces the read of the 64 bit value
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
wrote:
>
> do_hres() is called from several places, so GCC doesn't inline
> it at first.
>
> do_hres() takes a struct __kernel_timespec * parameter for
> passing the result. In the 32 bits case, this parameter corresponds
> to a local var in the cal
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
wrote:
>
> On powerpc, __arch_get_vdso_data() clobbers the link register,
> requiring the caller to set a stack frame in order to save it.
>
> As the parent function already has to set a stack frame and save
> the link register to call the C vdso fu
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
wrote:
>
> On powerpc, VDSO functions and syscalls cannot be implemented in C
> because the Linux kernel ABI requires that CR[SO] bit is set in case
> of error and cleared when no error.
>
> As this cannot be done in C, C VDSO functions and syscall'
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
wrote:
>
> In order to simplify next step which moves fallback call at arch
> level, ensure all arches have a 32bit fallback instead of handling
> the lack of 32bit fallback in the common code based
> on VDSO_HAS_32BIT_FALLBACK
I don't like this.
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
wrote:
>
> VDSO_HRES and VDSO_RAW clocks are handled the same way.
>
> Don't duplicate code.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Andy Lutomirski
ction really ought to be considered deprecated -- 32-bit
time_t is insufficient.
Do you get even better code if you move the read into the if statement?
Reviewed-by: Andy Lutomirski
--Andy
On Tue, Oct 22, 2019 at 6:56 AM Christophe Leroy
wrote:
>
>
> >>> The performance is rather disappoiting. That's most likely all
> >>> calculation in the C implementation are based on 64 bits math and
> >>> converted to 32 bits at the very end. I guess C implementation should
> >>> use 32 bits mat
> On Sep 7, 2019, at 10:45 AM, Linus Torvalds
> wrote:
>
>> On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski wrote:
>>
>> Linus, you rejected resolveat() because you wanted a *nice* API
>
> No. I rejected resoveat() because it was a completely broken ga
> On Sep 7, 2019, at 9:58 AM, Linus Torvalds
> wrote:
>
>> On Sat, Sep 7, 2019 at 5:40 AM Jeff Layton wrote:
>>
>> After thinking about this a bit, I wonder if we might be better served
>> with a new set of OA2_* flags instead of repurposing the O_* flags?
>
> I'd hate to have yet _another
> On Aug 18, 2019, at 8:58 PM, Daniel Axtens wrote:
>
>>> Each page of shadow memory represent 8 pages of real memory. Could we use
>>> page_ref to count how many pieces of a shadow page are used so that we can
>>> free it when the ref count decreases to 0.
>
> I'm not sure how much of a differen
On Fri, Aug 16, 2019 at 10:08 AM Mark Rutland wrote:
>
> Hi Christophe,
>
> On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote:
> > Le 15/08/2019 à 02:16, Daniel Axtens a écrit :
> > > Hook into vmalloc and vmap, and dynamically allocate real shadow
> > > memory to back the mappings.
On Mon, Mar 18, 2019 at 3:49 AM Sudeep Holla wrote:
>
> Now that we have a new hook ptrace_syscall_enter that can be called from
> syscall entry code and it handles PTRACE_SYSEMU in generic code, we
> can do some cleanup using the same in syscall_trace_enter.
>
> Further the extra logic to find si
On Mon, Mar 18, 2019 at 3:49 AM Sudeep Holla wrote:
>
> Hi,
>
> This patchset evolved from the discussion in the thread[0][1]. When we
> wanted to add PTRACE_SYSEMU support to ARM64, we thought instead of
> duplicating what other architectures like x86 and powerpc have done,
> let consolidate the
1 - 100 of 186 matches
Mail list logo
