On Thu, Oct 29 2020 at 23:18, Thomas Gleixner wrote:
>
> There is also a still to be investigated question from Linus on the initial
> posting versus the per cpu / per task mapping stack depth which might need
> to be made larger due to the ability to take page faults within a mapping
> region.
I
On Sat, Oct 31, 2020 at 4:04 PM Christophe Leroy
wrote:
> > There are also some users on 10+ year old 32-bit netbooks or
> > business laptops, both x86 and Apple G4.
> > The longest-lived 32-bit embedded systems with large memory
> > (other than Arm) are probably NXP QorIQ P20xx/P40xx used in
> >
There are also some users on 10+ year old 32-bit netbooks or
business laptops, both x86 and Apple G4.
The longest-lived 32-bit embedded systems with large memory
(other than Arm) are probably NXP QorIQ P20xx/P40xx used in
military VME bus systems, and low-end embedded systems based
on
On Fri, Oct 30, 2020 at 11:46 PM Linus Torvalds
wrote:
>
> On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
> >
> > While at it I might have a look at that debug request from Willy in the
> > other end of this thread. Any comment on that?
> >
> >
On Sat, Oct 31 2020 at 00:26, Thomas Gleixner wrote:
> On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote:
>> On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
>> To me, your patch series has two big advantages:
>>
>> - more common code
>>
>> - kmap_local() becomes more of a no-op
>>
>>
On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote:
> On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
> To me, your patch series has two big advantages:
>
> - more common code
>
> - kmap_local() becomes more of a no-op
>
> and the last thing we want is to expand on kmap.
Happy to go
On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
>
> While at it I might have a look at that debug request from Willy in the
> other end of this thread. Any comment on that?
>
> https://lore.kernel.org/r/87k0v7mrrd@nanos.tec.linutronix.de
I do think that it would be nice to have a
On Fri, Oct 30 2020 at 13:28, Linus Torvalds wrote:
> On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote:
>>
>> But then we really should not name it kmap_local. 'local' suggests
>> locality, think local_irq*, local_bh* ... kmap_task would be more
>> accurate then.
>
> So the main reason I'd
On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote:
>
> But then we really should not name it kmap_local. 'local' suggests
> locality, think local_irq*, local_bh* ... kmap_task would be more
> accurate then.
So the main reason I'd like to see it is because I think on a
non-highmem machine,
On Fri, Oct 30 2020 at 13:06, Matthew Wilcox wrote:
> On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
>> This series provides kmap_local.* iomap_local variants which only disable
>> migration to keep the virtual mapping address stable accross preemption,
>> but do neither disable
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
> This series provides kmap_local.* iomap_local variants which only disable
> migration to keep the virtual mapping address stable accross preemption,
> but do neither disable pagefaults nor preemption. The new functions can be
>
On Fri, Oct 30 2020 at 08:25, Christoph Hellwig wrote:
> On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
>> - Consolidating all kmap atomic implementations in generic code
>
> I think the consolidation is a winner no matter where we go next. Maybe
> split it out in a prep series
On Fri, Oct 30 2020 at 00:41, Thomas Gleixner wrote:
> On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote:
> No, you're not misreading it, but doing it conditionally would be a
> complete semantical disaster. kmap_atomic*() also disables preemption
> and pagefaults unconditionaly. If that
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
> This is achieved by:
...
>
> - Consolidating all kmap atomic implementations in generic code
...
> Though I wanted to share the current state of affairs before investigating
> that further. If there is consensus in going
On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote:
> On Thu, Oct 29, 2020 at 3:32 PM Thomas Gleixner wrote:
>>
>> Though I wanted to share the current state of affairs before investigating
>> that further. If there is consensus in going forward with this, I'll have a
>> deeper look into this
On Thu, Oct 29, 2020 at 3:32 PM Thomas Gleixner wrote:
>
>
> Though I wanted to share the current state of affairs before investigating
> that further. If there is consensus in going forward with this, I'll have a
> deeper look into this issue.
Me likee. I think this looks like the right thing
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de
and the initial version of this:
https://lore.kernel.org/r/20200919091751.06...@linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
Now that
17 matches
Mail list logo
