On Mon 09-04-18 15:03:45, Bart Van Assche wrote:
> On Mon, 2018-04-09 at 11:00 +0200, Michal Hocko wrote:
> > On Mon 09-04-18 04:46:22, Bart Van Assche wrote:
> > [...]
> > [...]
> > > diff --git a/drivers/ide/ide-pm.c b/drivers/ide/ide-pm.c
> > >
ectly. I guess you wanted to
have GFP_NOIO semantic, right? So why not be explicit about that. Same
for other instances of this flag in the patch
--
Michal Hocko
SUSE Labs
On Tue 06-03-18 20:28:59, Tetsuo Handa wrote:
> Laura Abbott wrote:
> > On 02/26/2018 06:28 AM, Michal Hocko wrote:
> > > On Fri 23-02-18 11:51:41, Laura Abbott wrote:
> > >> Hi,
> > >>
> > >> The Fedora arm-32 build VMs have a somewha
On Mon 05-03-18 13:04:24, Laura Abbott wrote:
> On 02/26/2018 06:28 AM, Michal Hocko wrote:
> > On Fri 23-02-18 11:51:41, Laura Abbott wrote:
> > > Hi,
> > >
> > > The Fedora arm-32 build VMs have a somewhat long standing problem
> > > of hanging whe
kernel memory. Have you tried to enable
highmem_is_dirtyable?
--
Michal Hocko
SUSE Labs
On Wed 06-12-17 15:36:56, Kirill Tkhai wrote:
> On 06.12.2017 15:23, Michal Hocko wrote:
> > On Tue 05-12-17 13:00:54, Kirill Tkhai wrote:
> > [...]
> >> This meets the problem in case of many containers
> >> are used on the hardware node. Since aio_max_nr is
>
.@virtuozzo.com
and read the above paragraph once again. I can see how accounting to
a memcg helps to reduce the memory footprint but I fail to see how it
helps the above scenario. Could you clarify wow you set up a limit to
prevent anybody from DoSing other containers by depleting aio_max_nr?
--
Michal Hocko
SUSE Labs
On Tue 05-12-17 19:02:00, Kirill Tkhai wrote:
> On 05.12.2017 18:43, Michal Hocko wrote:
> > On Tue 05-12-17 18:34:59, Kirill Tkhai wrote:
> >> On 05.12.2017 18:15, Michal Hocko wrote:
> >>> On Tue 05-12-17 13:00:54, Kirill Tkhai wrote:
> >>>> Cu
On Tue 05-12-17 18:34:59, Kirill Tkhai wrote:
> On 05.12.2017 18:15, Michal Hocko wrote:
> > On Tue 05-12-17 13:00:54, Kirill Tkhai wrote:
> >> Currently, number of available aio requests may be
> >> limited only globally. There are two sysctl variables
> >> ai
t happens when we hit the hard limit and oom kill somebody?
Are those charged objects somehow bound to a process context?
--
Michal Hocko
SUSE Labs
w. It doesn't matter
> > which one I choose, but I prefer to split it.
>
> I don't know whether it's better to make it all one patch or split it
> into multiple patches. But it makes no sense to introduce it in struct
> page, then move it to struct page_ext.
I would tend to agree. It is not like anybody would like to apply only
the first part alone. Adding the necessary infrastructure to page_ext is
not such a big deal.
--
Michal Hocko
SUSE Labs
On Fri 24-11-17 12:02:36, Byungchul Park wrote:
> On Thu, Nov 16, 2017 at 02:07:46PM +0100, Michal Hocko wrote:
> > On Thu 16-11-17 21:48:05, Byungchul Park wrote:
> > > On 11/16/2017 9:02 PM, Michal Hocko wrote:
> > > > for each struct page. So you are d
On Thu 16-11-17 21:48:05, Byungchul Park wrote:
> On 11/16/2017 9:02 PM, Michal Hocko wrote:
> > for each struct page. So you are doubling the size. Who is going to
> > enable this config option? You are moving this to page_ext in a later
> > patch which is a good step but it
e? Something we do for page_owner for
example?
Also it would be really great if you could give us some measures about
the runtime overhead. I do not expect it to be very large but this is
something people are usually interested in when enabling debugging
features.
--
Michal Hocko
SUSE Labs
On Thu 06-04-17 09:33:44, Adrian Hunter wrote:
> On 05/04/17 14:39, Vlastimil Babka wrote:
> > On 04/05/2017 01:36 PM, Richard Weinberger wrote:
> >> Michal,
> >>
> >> Am 05.04.2017 um 13:31 schrieb Michal Hocko:
> >>> On Wed 05-04-17 09:47:0
ags.
So while I do not have a strong opinion on this I think defining loop
specific thread function which set PF_LESS_THROTTLE as the first thing
is more elegant and less error prone longerm. A short comment explaining
why we use the flag there would be also preferred.
I will leave the decision to you.
Thanks.
--
Michal Hocko
SUSE Labs
On Wed 05-04-17 13:39:16, Vlastimil Babka wrote:
> On 04/05/2017 01:36 PM, Richard Weinberger wrote:
> > Michal,
> >
> > Am 05.04.2017 um 13:31 schrieb Michal Hocko:
> >> On Wed 05-04-17 09:47:00, Vlastimil Babka wrote:
> >>> Nandsim has own f
;
> - int err, memalloc;
> + int err;
> + unsigned int noreclaim_flag;
>
> err = get_pages(ns, file, count, pos);
> if (err)
> return err;
> - memalloc = set_memalloc();
> + noreclaim_flag = memalloc_noreclaim_save();
> tx = kernel_write(file, buf, count, pos);
> - clear_memalloc(memalloc);
> + memalloc_noreclaim_restore(noreclaim_flag);
> put_pages(ns);
> return tx;
> }
> --
> 2.12.2
--
Michal Hocko
SUSE Labs
, but the change makes it
> more
> robust.
>
> Suggested-by: Michal Hocko <mho...@suse.com>
> Signed-off-by: Vlastimil Babka <vba...@suse.cz>
One could argue that tsk_restore_flags() could be extended to provide
tsk_set_flags() and use it for all allocation related PF fl
in <aryabi...@virtuozzo.com>
> Signed-off-by: Vlastimil Babka <vba...@suse.cz>
> Cc: <sta...@vger.kernel.org>
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> mm/page_alloc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/m
On Wed 05-04-17 09:19:27, Michal Hocko wrote:
> On Wed 05-04-17 14:33:50, NeilBrown wrote:
[...]
> > diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> > index 0ecb6461ed81..44b3506fd086 100644
> > --- a/drivers/block/loop.c
> > +++ b/drivers/block/loop.c
> &g
er improvement as the total overhead still
> seems too high, but this is a big improvement.
>
> Reviewed-by: Christoph Hellwig <h...@lst.de>
> Acked-by: Michal Hocko <mho...@suse.com>
> Signed-off-by: NeilBrown <ne...@suse.com>
> ---
>
> I moved where the
er improvement as the total overhead still
> seems too high, but this is a big improvement.
Yes this makes sense to me
> Signed-off-by: NeilBrown <ne...@suse.com>
Acked-by: Michal Hocko <mho...@suse.com>
one nit below
> ---
> drivers/block/loop.c | 3 +++
>
On Thu 08-12-16 07:30:43, James Bottomley wrote:
> On Thu, 2016-12-08 at 13:26 +0100, Michal Hocko wrote:
> > On Wed 07-12-16 06:57:06, James Bottomley wrote:
> > [...]
> > > Just on this point, since there seems to be a lot of confusion: lsf
> > > -pc
use we
> expect you to cc the relevant existing mailing list and have the
> discussion there instead rather than expecting people to subscribe to a
> new list.
There used to be l...@lists.linux-foundation.org. Is it not active
anymore?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from
25 matches
Mail list logo
