On Mon, Nov 23 2020 at 14:07, Andy Lutomirski wrote:
>> On Nov 23, 2020, at 1:25 PM, Thomas Gleixner wrote:
>> On Mon, Nov 23 2020 at 22:15, Thomas Gleixner wrote:
On Sun, Nov 22 2020 at 15:16, Andy Lutomirski wrote:
The common case of a CPU switching back and forth between a
> On Nov 23, 2020, at 1:25 PM, Thomas Gleixner wrote:
>
> On Mon, Nov 23 2020 at 22:15, Thomas Gleixner wrote:
>>> On Sun, Nov 22 2020 at 15:16, Andy Lutomirski wrote:
On Fri, Nov 20, 2020 at 1:29 AM Peter Zijlstra
wrote:
>>> The common case of a CPU switching back and forth
On Mon, Nov 23 2020 at 22:15, Thomas Gleixner wrote:
> On Sun, Nov 22 2020 at 15:16, Andy Lutomirski wrote:
>> On Fri, Nov 20, 2020 at 1:29 AM Peter Zijlstra wrote:
>> The common case of a CPU switching back and forth between a small
>> number of mms would have no significant overhead.
>
> For
On Sun, Nov 22 2020 at 15:16, Andy Lutomirski wrote:
> On Fri, Nov 20, 2020 at 1:29 AM Peter Zijlstra wrote:
>> Anyway, clearly I'm the only one that cares, so I'll just crawl back
>> under my rock...
>
> I'll poke my head out of the rock for a moment, though...
>
> Several years ago, we
On Fri, Nov 20, 2020 at 1:29 AM Peter Zijlstra wrote:
>
> As already stated, per-cpu page-tables would allow for a much saner kmap
> approach, but alas, x86 really can't sanely do that (the archs that have
> separate kernel and user page-tables could do this, and how we cursed
> x86 didn't have
On Fri, Nov 20, 2020 at 02:33:58AM +0100, Thomas Gleixner wrote:
> On Thu, Nov 19 2020 at 19:28, Peter Zijlstra wrote:
> > On Thu, Nov 19, 2020 at 09:23:47AM -0800, Linus Torvalds wrote:
> >> Because this is certainly not the only time migration limiting has
> >> come up, and no, it has absolutely
On Thu, Nov 19 2020 at 19:28, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 09:23:47AM -0800, Linus Torvalds wrote:
>> Because this is certainly not the only time migration limiting has
>> come up, and no, it has absolutely nothing to do with per-cpu page
>> tables being completely unacceptable.
On Thu, Nov 19, 2020 at 09:23:47AM -0800, Linus Torvalds wrote:
> On Thu, Nov 19, 2020 at 3:14 AM Peter Zijlstra wrote:
> >
> > I still hate all of this, and I really fear that with migrate_disable()
> > available, people will be lazy and usage will increase :/
> >
> > Case at hand is this
On Thu, Nov 19, 2020 at 3:14 AM Peter Zijlstra wrote:
>
> I still hate all of this, and I really fear that with migrate_disable()
> available, people will be lazy and usage will increase :/
>
> Case at hand is this series, the only reason we need it here is because
> per-cpu page-tables are
On Thu, 19 Nov 2020 12:14:13 +
Mel Gorman wrote:
> * Usage of migrate_disable is heavily discouraged as it is extremely
> * hazardous on PREEMPT_RT kernels and any usage needs to be heavily
I don't believe it's just PREEMPT_RT. It's RT tasks that are concerned,
especially when you are
On Thu, Nov 19, 2020 at 12:14:11PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 09:38:34AM +, Mel Gorman wrote:
> > On Wed, Nov 18, 2020 at 08:48:42PM +0100, Thomas Gleixner wrote:
> > > From: Thomas Gleixner
> > >
> > > Now that the scheduler can deal with migrate disable
On Thu, Nov 19, 2020 at 09:38:34AM +, Mel Gorman wrote:
> On Wed, Nov 18, 2020 at 08:48:42PM +0100, Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > Now that the scheduler can deal with migrate disable properly, there is no
> > real compelling reason to make it only available for RT.
On Wed, Nov 18, 2020 at 08:48:42PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Now that the scheduler can deal with migrate disable properly, there is no
> real compelling reason to make it only available for RT.
>
> There are quite some code pathes which needlessly disable
From: Thomas Gleixner
Now that the scheduler can deal with migrate disable properly, there is no
real compelling reason to make it only available for RT.
There are quite some code pathes which needlessly disable preemption in
order to prevent migration and some constructs like kmap_atomic()
14 matches
Mail list logo
