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 small
> 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 betwe
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 CPU
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 discussed
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 t
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 series,
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 expens
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 dealin
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 properly,
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 preempt
13 matches
Mail list logo
