On Fri 21-06-13 16:09:38, Michal Hocko wrote:
> On Fri 21-06-13 16:06:27, Michal Hocko wrote:
> [...]
> > > Can you try this monolithic patch please?
> >
> > Wow, this looks much better!
>
> Damn it! Scratch that. I have made a mistake in configuration so this
On Fri 21-06-13 17:04:30, Michal Hocko wrote:
> On Fri 21-06-13 16:09:38, Michal Hocko wrote:
> > On Fri 21-06-13 16:06:27, Michal Hocko wrote:
> > [...]
> > > > Can you try this monolithic patch please?
> > >
> > > Wow, this looks much better!
On Thu 20-06-13 12:12:06, Mel Gorman wrote:
> On Tue, Jun 18, 2013 at 02:09:39PM +0200, Michal Hocko wrote:
> > base is mmotm-2013-05-09-15-57
> > baserebase is mmotm-2013-06-05-17-24-63 + patches from the current mmots
> > without slab shrinkers patchset.
> > reworkreba
t;
> > Signed-off-by: Luiz Capitulino
> Acked-by: Minchan Kim
>
> Shouldn't we make this default?
The interface is not there for long but still, changing it is always
quite tricky. And the users who care can be modified really easily so I
would stick with the original defaul
if (strncmp(++p, "strict", 6))
> + return -EINVAL;
> + smode = true;
> + }
> +
> ev = kzalloc(sizeof(*ev), GFP_KERNEL);
> if (!ev)
> return -ENOMEM;
>
> ev->efd = eventfd;
> ev-
On Tue 25-06-13 12:27:54, Dave Chinner wrote:
> On Tue, Jun 18, 2013 at 03:50:25PM +0200, Michal Hocko wrote:
> > And again, another hang. It looks like the inode deletion never
> > finishes. The good thing is that I do not see any LRU related BUG_ONs
> > anymore. I am going t
On Sun 23-06-13 15:51:29, Glauber Costa wrote:
> On Fri, Jun 21, 2013 at 11:00:21AM +0200, Michal Hocko wrote:
> > On Thu 20-06-13 17:12:01, Michal Hocko wrote:
> > > I am bisecting it again. It is quite tedious, though, because good case
> > > is hard to be sure a
le reworking the OOM routine, also remove a needless OOM waitqueue
wakeup when invoking the killer. Only uncharges and limit increases,
things that actually change the memory situation, should do wakeups.
Reported-by: Reported-by: azurIt
Debugged-by: Michal Hocko
Reported-by: David Rientjes
On Fri 07-06-13 17:13:55, Piotr Nowojski wrote:
> W dniu 06.06.2013 17:57, Michal Hocko pisze:
> >>>In our system we have hit some very annoying situation (bug?) with
> >>>cgroups. I'm writing to you, because I have found your posts on
> >>>mailing lists
p for first non-NULL without calling
+* cgroup_next_descendant_pre afterwards.
+*/
prev_cgroup = cgroup_rightmost_descendant(next_cgroup);
goto skip_node;
case VISIT:
--
Michal Hocko
On Wed 05-06-13 17:09:17, David Rientjes wrote:
> On Wed, 5 Jun 2013, Michal Hocko wrote:
>
> > > For the aforementioned reason that we give users the ability to
> > > manipulate
> > > their own memcg trees and userspace is untrusted. Their oom notifiers
>
On Tue 11-06-13 10:35:01, Piotr Nowojski wrote:
> W dniu 07.06.2013 17:36, Michal Hocko pisze:
> >On Fri 07-06-13 17:13:55, Piotr Nowojski wrote:
> >>W dniu 06.06.2013 17:57, Michal Hocko pisze:
> >>>>>In our system we have hit some very annoying situation (bu
e new series.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ad. I also notice that azurIt isn't cc'd on this thread. Do we
> know if this is still a problem?
I have backported the patch for his 3.2 and waiting for his feedback.
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe
On Mon 01-07-13 18:10:56, Dave Chinner wrote:
> On Mon, Jul 01, 2013 at 09:50:05AM +0200, Michal Hocko wrote:
> > On Mon 01-07-13 11:25:58, Dave Chinner wrote:
> > > On Sun, Jun 30, 2013 at 08:33:49PM +0200, Michal Hocko wrote:
> > > > On Sat 29-06-13 12:55:09, Dave C
time ago.
I plan to look at the at some point but I am rather busy with other
stuff right now. That would be just a first step though. Then we need to
hook into dirty pages throttling and make it memcg aware which sounds
like a bigger challenge.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this
y with crash and check all the juicy
internals.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
would see Medium while critical is waiting for being
scheduled.
Kernel might help here though and signal from the highest event down to
lower ones. The core issue would stay though. What is a tolerable period
when an event is considered separate one?
That being said I think both modes make sense and t
a single cleanup
function for whole kmem. If that one needs to do tcp kmem specific
cleanup then it should be done inside kmem_cgroup_css_offline.
Andrew could you add this as
memcg-use-css_get-put-when-charging-uncharging-kmem-fix.patch, please?
Acked-by: Michal Hocko
Thanks
> ---
&g
On Wed 03-07-13 17:34:15, Joonsoo Kim wrote:
[...]
> For one page allocation at once, this patchset makes allocator slower than
> before (-5%).
Slowing down the most used path is a no-go. Where does this slow down
come from?
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from thi
: update address_space_operations
documentation: document the is_dirty_writeback aops callback
mm: vmscan: do not continue scanning if reclaim was aborted for compaction
mm: vmscan: do not scale writeback pages when deciding whether to set
ZONE_WRITEBACK
Michal Hocko (4):
On Wed 03-07-13 17:53:21, Sedat Dilek wrote:
> On Wed, Jul 3, 2013 at 5:20 PM, Michal Hocko wrote:
> > On Wed 03-07-13 20:51:00, Li Zefan wrote:
> > [...]
> >> [PATCH] memcg: fix build error if CONFIG_MEMCG_KMEM=n
> >>
> >> Fix this build e
On Wed 03-07-13 18:11:28, Sedat Dilek wrote:
> On Wed, Jul 3, 2013 at 5:59 PM, Michal Hocko wrote:
> > On Wed 03-07-13 17:53:21, Sedat Dilek wrote:
> >> On Wed, Jul 3, 2013 at 5:20 PM, Michal Hocko wrote:
> >> > On Wed 03-07-13 20:51:00, Li Zefan wrote:
> >
On Thu 04-07-13 13:24:50, Joonsoo Kim wrote:
> On Thu, Jul 04, 2013 at 12:01:43AM +0800, Zhang Yanfei wrote:
> > On 07/03/2013 11:51 PM, Zhang Yanfei wrote:
> > > On 07/03/2013 11:28 PM, Michal Hocko wrote:
> > >> On Wed 03-07-13 17:34:15, Joonsoo Kim wrote:
>
.
This patch saves the user defined value and allows updating
min_free_kbytes only if it is higher than the saved one.
A warning is printed when the new value is ignored.
Signed-off-by: Michal Hocko
---
mm/page_alloc.c | 25 ++---
1 file changed, 18 insertions(+), 7
On Thu 04-07-13 09:10:39, Joe Perches wrote:
> On Thu, 2013-07-04 at 18:07 +0200, Michal Hocko wrote:
> > A warning is printed when the new value is ignored.
>
> []
>
> > + printk(KERN_WARNING "min_free_kbytes is not updated to %d"
> > +
On Thu 04-07-13 18:16:41, Michal Hocko wrote:
> On Thu 04-07-13 09:10:39, Joe Perches wrote:
> > On Thu, 2013-07-04 at 18:07 +0200, Michal Hocko wrote:
> > > A warning is printed when the new value is ignored.
> >
> > []
> >
> > > + printk(KE
On Wed 03-07-13 21:24:03, Dave Chinner wrote:
> On Tue, Jul 02, 2013 at 02:44:27PM +0200, Michal Hocko wrote:
> > On Tue 02-07-13 22:19:47, Dave Chinner wrote:
> > [...]
> > > Ok, so it's been leaked from a dispose list somehow. Thanks for the
> > > info, Mi
This
causes module loading failure even if the given algorithm is supported:
[0.815330] zcache: compressor initialization failed
Reported-by: Cristian RodrÃguez
Signed-off-by: Michal Hocko
---
drivers/staging/zcache/zcache-main.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
al.
>
> Strict mode solves this problem by strictly notifiying an eventfd
> for the pressure level it registered for. This new mode is optional,
> by default we still notify eventfds on higher levels too.
>
> Signed-off-by: Luiz Capitulino
Two nits bellow but it looks good in gener
On Thu 27-06-13 09:24:26, Dave Chinner wrote:
> On Wed, Jun 26, 2013 at 10:15:09AM +0200, Michal Hocko wrote:
> > On Tue 25-06-13 12:27:54, Dave Chinner wrote:
> > > On Tue, Jun 18, 2013 at 03:50:25PM +0200, Michal Hocko wrote:
> > > > And again, another hang. It
On Thu 27-06-13 09:34:07, Luiz Capitulino wrote:
> On Thu, 27 Jun 2013 11:26:16 +0200
> Michal Hocko wrote:
> > On Wed 26-06-13 23:17:12, Luiz Capitulino wrote:
[...]
> > > +Applications can also choose between two notification modes when
> > > +registering an even
On Fri 28-06-13 00:53:57, Minchan Kim wrote:
> On Thu, Jun 27, 2013 at 11:26:16AM +0200, Michal Hocko wrote:
[...]
> > I still think that edge triggering makes some sense but that one might
> > be rebased on top of this patch. We should still figure out whether the
> > edge tr
%r15
81127ee6: c9 leaveq
81127ee7: c3 retq
We are tripping over in list_for_each_safe and r14(00572ead7838) is
obviously a garbage. So the lru is clobbered?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the l
On Fri 28-06-13 18:31:26, Glauber Costa wrote:
> On Fri, Jun 28, 2013 at 10:39:43AM +0200, Michal Hocko wrote:
> > I have just triggered this one.
> >
> > [37955.364062] RIP: 0010:[] []
> > list_lru_walk_node+0xab/0x140
> > [37955.364062] RSP: :f
ious users who are not willing to jump in to the systemd
car, doesn't sound like a good place where to place the new interface to
me.
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sat 29-06-13 12:55:09, Dave Chinner wrote:
> On Thu, Jun 27, 2013 at 04:54:11PM +0200, Michal Hocko wrote:
> > On Thu 27-06-13 09:24:26, Dave Chinner wrote:
> > > On Wed, Jun 26, 2013 at 10:15:09AM +0200, Michal Hocko wrote:
> > > > On Tue 25-06-13 12:27:54, Dave C
On Fri 28-06-13 14:01:55, Vivek Goyal wrote:
> On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
[...]
> > OK, so libcgroup's rules daemon will still work and place my tasks in
> > appropriate cgroups?
>
> Do you use that daemon in practice?
I am not but my
On Mon 01-07-13 11:25:58, Dave Chinner wrote:
> On Sun, Jun 30, 2013 at 08:33:49PM +0200, Michal Hocko wrote:
> > On Sat 29-06-13 12:55:09, Dave Chinner wrote:
> > > On Thu, Jun 27, 2013 at 04:54:11PM +0200, Michal Hocko wrote:
> > > > On Thu 27-06-13 09:24:26, Dave C
d-off-by: Mel Gorman
OK, looks good.
Reviewed-by: Michal Hocko
> ---
> mm/vmscan.c | 28 +---
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 7d5a932..84375b2 100644
> --- a/mm/vmscan.c
> +++ b
per priority if kswapd should be writing pages.
Except it is not once per priority strictly speaking... It doesn't make
any difference though.
> Signed-off-by: Mel Gorman
Reviewed-by: Michal Hocko
> ---
> mm/vmscan.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 d
zone reaches its high watermark,
> - * consider it to be no longer congested. It's
> - * possible there are dirty pages backed by
> - * congested BDIs but as pressure is relieved,
> - * speculatively avoid congestion waits
> - */
> - zone_clear_flag(zone, ZONE_CONGESTED);
> + nr_to_reclaim += sc.nr_to_reclaim;
> }
nr_to_reclaim is updated if the zone is balanced an no reclaim is done
which break compaction condition AFAICS.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu 21-03-13 15:34:42, Mel Gorman wrote:
> On Thu, Mar 21, 2013 at 04:07:55PM +0100, Michal Hocko wrote:
> > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > > index 4835a7a..182ff15 100644
> > > > > --- a/mm/vmscan.c
> > > &
On Fri 22-03-13 09:22:06, Li Zefan wrote:
> On 2013/3/21 18:22, Michal Hocko wrote:
> > On Thu 21-03-13 10:08:49, Michal Hocko wrote:
> >> On Thu 21-03-13 09:22:21, Li Zefan wrote:
> >>> As cgroup supports rename, it's unsafe to dereference dentry->d_name
&g
he actual memcg
> allocation is short lived.
OK, I have totally missed that. Sorry about the confusion. Then all the
churn around the allocation is pointless, no?
What about:
---
>From 7ed7f53bb597e8cb40d9ac91ce16142fb60f1e93 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Fri, 22 Mar 20
On Fri 22-03-13 13:41:40, Glauber Costa wrote:
> On 03/22/2013 01:31 PM, Michal Hocko wrote:
> > On Fri 22-03-13 12:22:23, Glauber Costa wrote:
> >> On 03/22/2013 12:17 PM, Li Zefan wrote:
> >>>> GFP_TEMPORARY groups short lived allocations but the mem cache is
On Fri 22-03-13 08:37:04, Mel Gorman wrote:
> On Fri, Mar 22, 2013 at 08:54:27AM +0100, Michal Hocko wrote:
> > On Thu 21-03-13 15:34:42, Mel Gorman wrote:
> > > On Thu, Mar 21, 2013 at 04:07:55PM +0100, Michal Hocko wrote:
> > > > > > > diff --git a/mm/vms
On Fri 22-03-13 14:03:30, Glauber Costa wrote:
> On 03/22/2013 01:48 PM, Michal Hocko wrote:
> > On Fri 22-03-13 13:41:40, Glauber Costa wrote:
> >> On 03/22/2013 01:31 PM, Michal Hocko wrote:
> >>> On Fri 22-03-13 12:22:23, Glauber Costa wrote:
> >>&g
On Fri 22-03-13 11:04:49, Michal Hocko wrote:
> On Fri 22-03-13 08:37:04, Mel Gorman wrote:
> > On Fri, Mar 22, 2013 at 08:54:27AM +0100, Michal Hocko wrote:
> > > On Thu 21-03-13 15:34:42, Mel Gorman wrote:
> > > > On Thu, Mar 21, 2013 at 04:07:55PM +0100, Michal Hoc
On Fri 22-03-13 14:25:23, Glauber Costa wrote:
> On 03/22/2013 02:06 PM, Michal Hocko wrote:
> > On Fri 22-03-13 14:03:30, Glauber Costa wrote:
> >> On 03/22/2013 01:48 PM, Michal Hocko wrote:
> >>> On Fri 22-03-13 13:41:40, Glauber Costa wrote:
> >>>&g
if (nr_slab == 0 && !zone_reclaimable(zone))
- zone->all_unreclaimable = 1;
- }
+ balance_gap, end_zone))
+ kswapd_shrink_zone(zone, &sc, lru_pages);
t; You guys can add my Acked-by, and thanks again
> >
> > Li, are you ok to take the page via your tree?
> >
>
> I don't have a git tree in kernel.org. It's Tejun that picks up
> cgroup patches.
Oh, I thought both of you push to that tree. Anyway, I will rework th
n is short lived.
> >
> > OK, I have totally missed that. Sorry about the confusion. Then all the
> > churn around the allocation is pointless, no?
> > What about:
> > ---
> >>From 7ed7f53bb597e8cb40d9ac91ce16142fb60f1e93 Mon Sep 17 00:00:00 2001
> > Fro
as kswapd will
> reclaim excessively if it is to balance zones for high-order allocations.
>
> Signed-off-by: Mel Gorman
It seems I forgot to add
Reviewed-by: Michal Hocko
> ---
> mm/vmscan.c | 53 +
> 1 file changed, 2
#ifdef CONFIG_BLOCK
> /* Returns true if all buffers are successfully locked */
> static bool buffer_migrate_lock_buffers(struct buffer_head *head,
> --
> 1.7.11.7
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
private,
> + enum migrate_mode mode, int reason)
> +{
> + int err = 0;
> +
> + if (!list_empty(from)) {
> + err = migrate_pages(from, get_new_page, private, mode, reason);
> + if (err)
> + putback_movable_page
ack_active_hugepage(hpage);
And why do you put it here? If it is called from migrate_pages then the
caller already does the clean-up (putback_lru_pages).
> put_page(new_hpage);
> if (result) {
> if (rc)
> --
> 1.7.11.7
>
--
Michal Hocko
SUSE Labs
--
To
migrate_pages doesn't do putback cleanup
on its own but migrate_movable_pages does?
Please also move migrate_movable_pages definition to this patch.
> }
>
> /*
> --
> 1.7.11.7
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linu
goto put_and_set;
> + }
Why do you take an additional reference here? You have one from
follow_page already.
> +
> err = isolate_lru_page(page);
> if (!err) {
> list_add_tail(&page->lru, &pagelist);
[...]
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
_VALUE(new_hpage))
> return -ENOMEM;
Please no. get_new_page returns NULL or a page. You are hooking a wrong
callback here. The error value doesn't make any sense here. IMO you
should just wrap alloc_huge_page by something that returns NULL or page.
>
> rc
urn 0;
> @@ -1247,6 +1256,21 @@ do_migrate_range(unsigned long start_pfn, unsigned
> long end_pfn)
> if (!pfn_valid(pfn))
> continue;
> page = pfn_to_page(pfn);
> +
> + if (PageHuge(page)) {
> + struct page *head = com
"This knob is obsolete and has no effect. It is scheduled for
removal")
> return 0;
> }
>
> --
> 1.7.11.7
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
atic char *tmp_name = NULL;
>
> (minor nitpick) why not preserve the name "name"
I wanted to make it clear that the name is just temporal
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
assert_held(&memcg_cache_mutex);
>
> rcu_read_lock();
> - dentry = rcu_dereference(memcg->css.cgroup->dentry);
> + cgname = cgroup_name(memcg->css.cgroup);
> rcu_read_unlock();
cgname is valid only within RCU read lock AFAIU.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue 26-03-13 00:33:35, Naoya Horiguchi wrote:
> On Mon, Mar 25, 2013 at 11:57:01AM +0100, Michal Hocko wrote:
> > On Fri 22-03-13 16:23:47, Naoya Horiguchi wrote:
[...]
> > > +int migrate_movable_pages(struct list_head *from, new_page_t
> > > get_new_page,
> >
On Tue 26-03-13 01:13:10, Naoya Horiguchi wrote:
> On Mon, Mar 25, 2013 at 02:04:16PM +0100, Michal Hocko wrote:
> > On Fri 22-03-13 16:23:50, Naoya Horiguchi wrote:
[...]
> > > @@ -1012,14 +1040,8 @@ static int migrate_to_node(struct mm_struct *mm,
> > > int source, in
On Tue 26-03-13 00:34:40, Naoya Horiguchi wrote:
> On Mon, Mar 25, 2013 at 01:31:28PM +0100, Michal Hocko wrote:
> > On Fri 22-03-13 16:23:48, Naoya Horiguchi wrote:
[...]
> > > @@ -1482,12 +1483,20 @@ static int soft_offline_huge_page(struct page
> > > *page, int flags
On Tue 26-03-13 03:06:18, Naoya Horiguchi wrote:
> On Mon, Mar 25, 2013 at 02:36:44PM +0100, Michal Hocko wrote:
> > On Fri 22-03-13 16:23:51, Naoya Horiguchi wrote:
[...]
> > > @@ -1514,8 +1515,9 @@ struct page *follow_page_mask(struct vm_area_struct
> > > *vma
+).
Thanks!
---
>From a786a701bd6c277329e2b788fea9a69b1c3ced2e Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 26 Mar 2013 19:04:40 +0100
Subject: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open
in error path
Starting with fdb40a08 (drm: set dev_mapping before call
it/commit/?id=787f7301074ccd07a3e82236ca41eefd245f4e07
> [2]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=53a59fc67f97374758e63a9c785891ec62324c81
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
[Forgot to add Peter]
On Wed 14-08-13 19:40:39, Michal Hocko wrote:
> [Let's CC some more people]
>
> On Wed 14-08-13 18:36:53, Ben Tebulin wrote:
> > Hello Michal, Johannes, Balbir, Kamezawa and Mailing lists!
>
> Hi,
>
> > Since v3.7.2 on two indep
On Wed 14-08-13 11:03:32, Linus Torvalds wrote:
> On Wed, Aug 14, 2013 at 10:40 AM, Michal Hocko wrote:
> >>
> >> After a _very long session of rebooting and bisecting_ the Linux kernel
> >> (fortunately I had a SSD and ccache!) I was able to pinpoint the cau
uot;, enable_swap_account);
>
> static void __init memsw_file_init(void)
> {
> --
> 1.8.3.2
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/
On Wed 14-08-13 20:36:04, Michal Hocko wrote:
> On Wed 14-08-13 15:21:35, Gergely Risko wrote:
> > Fixed swap accounting option parsing to enable if called without argument.
>
> We used to have [no]swapaccount but that one has been removed by a2c8990a
> (memsw: remove no
[Let's CC Andrew]
On Wed 14-08-13 23:22:23, Gergely Risko wrote:
> On Wed, 14 Aug 2013 20:49:56 +0200, Michal Hocko writes:
>
> > On Wed 14-08-13 20:36:04, Michal Hocko wrote:
> >> On Wed 14-08-13 15:21:35, Gergely Risko wrote:
> >> > Fixed swap account
> I'll think about this some more. I'm not happy with how that
> particular whole TLB flushing hack was done, but I need to sleep on
> this.
I am looking into it as well, but there are high prio things which
preempt me a lot :/
Thanks for looking into it.
--
Michal Hocko
SUSE Lab
On Thu 15-08-13 15:40:31, Michal Hocko wrote:
> On Thu 15-08-13 05:02:31, Linus Torvalds wrote:
> > On Thu, Aug 15, 2013 at 2:25 AM, Ben Tebulin wrote:
> > >
> > > I just cherry-picked e6c495a96ce0 into 3.9.11 and 3.7.10.
> > > Unfortunately this does _not re
On Thu 15-08-13 16:46:00, Michal Hocko wrote:
> On Thu 15-08-13 15:40:31, Michal Hocko wrote:
> > On Thu 15-08-13 05:02:31, Linus Torvalds wrote:
> > > On Thu, Aug 15, 2013 at 2:25 AM, Ben Tebulin
> > > wrote:
> > > >
> > > > I jus
On Thu 15-08-13 16:53:32, Michal Hocko wrote:
> On Thu 15-08-13 16:46:00, Michal Hocko wrote:
> > On Thu 15-08-13 15:40:31, Michal Hocko wrote:
> > > On Thu 15-08-13 05:02:31, Linus Torvalds wrote:
> > > > On Thu, Aug 15, 2013 at 2:25 AM, Ben Tebulin
> > &
king about teaching __tlb_remove_page to update the range
automatically from the given address.
But your patch looks good to me as well.
Feel free to add
Reviewed-by: Michal Hocko
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
On Thu 04-07-13 18:36:43, Michal Hocko wrote:
> On Wed 03-07-13 21:24:03, Dave Chinner wrote:
> > On Tue, Jul 02, 2013 at 02:44:27PM +0200, Michal Hocko wrote:
> > > On Tue 02-07-13 22:19:47, Dave Chinner wrote:
> > > [...]
> > > > Ok, so it's been le
d an OOM which has been handled by in-kernel oom handler
(it killed 12021) and 12037 was in the same group. The warning tells us
that it went through mem_cgroup_oom as well (otherwise it wouldn't have
memcg_oom.wait_on_memcg set and the warning wouldn't trigger) and then
it exited on the us
On Mon 15-07-13 17:41:19, Michal Hocko wrote:
> On Sun 14-07-13 01:51:12, azurIt wrote:
> > > CC: "Johannes Weiner" , linux-kernel@vger.kernel.org,
> > > linux...@kvack.org, "cgroups mailinglist" ,
> > > "KAMEZAWA Hiroyuki"
On Tue 16-07-13 11:35:44, Johannes Weiner wrote:
> On Mon, Jul 15, 2013 at 06:00:06PM +0200, Michal Hocko wrote:
> > On Mon 15-07-13 17:41:19, Michal Hocko wrote:
> > > On Sun 14-07-13 01:51:12, azurIt wrote:
> > > > > CC: "Johannes Weiner" ,
&g
e sense. I agree that the
changelog could have been much more specific and will try to do better
next time.
The patch fixes reference counting imbalance and potential
use-after-free.
> and seems we currently want to be more strictly on what patches should
> go into stable, I think it's f
On Mon 29-07-13 01:54:01, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Sun 28-07-13 17:42:28, Eric W. Biederman wrote:
> >> Tejun Heo writes:
> >>
> >> > Hello, Linus.
> >> >
> >> > This pull request contains two pat
On Fri 26-07-13 14:46:57, Johannes Weiner wrote:
> On Fri, Jul 26, 2013 at 03:52:07PM +0200, Michal Hocko wrote:
> > On Thu 25-07-13 18:25:36, Johannes Weiner wrote:
> > > The x86 fault handler bails in the middle of error handling when the
> > > task has a fatal signal
On Fri 26-07-13 17:28:09, Johannes Weiner wrote:
> On Fri, Jul 26, 2013 at 04:43:10PM +0200, Michal Hocko wrote:
> > On Thu 25-07-13 18:25:38, Johannes Weiner wrote:
> > > @@ -2189,31 +2191,20 @@ static void memcg_oom_recover(struct mem_cg
On Mon 29-07-13 17:24:53, Minchan Kim wrote:
> Hi Michal,
>
> On Thu, Jul 25, 2013 at 03:30:40PM +0200, Michal Hocko wrote:
> > On Wed 24-07-13 11:44:28, Minchan Kim wrote:
> > > On Tue, Jul 23, 2013 at 04:01:20PM +0200, Michal Hocko wrote:
> > > > On Fri
On Mon 29-07-13 10:55:29, Johannes Weiner wrote:
> On Mon, Jul 29, 2013 at 04:12:50PM +0200, Michal Hocko wrote:
> > On Fri 26-07-13 17:28:09, Johannes Weiner wrote:
> > > On Fri, Jul 26, 2013 at 04:43:10PM +0200, Michal Hocko wrote:
> > > > On Thu 25-07-13 1
harges will be gone
during offlining. Otherwise yes, it might take really long until slab
page will be freed.
> Maybe dropping cache would work?
KMEM is not used here so I do not think this would help.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mon 29-07-13 13:57:43, Andrew Morton wrote:
> On Fri, 26 Jul 2013 14:44:29 +0200 Michal Hocko wrote:
[...]
> > --- a/fs/drop_caches.c
> > +++ b/fs/drop_caches.c
> > @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler(ctl_table *table, int
> > write,
> > if
_oom_waitq, &owait.wait);
> + } else if (need_to_kill) {
> finish_wait(&memcg_oom_waitq, &owait.wait);
> mem_cgroup_out_of_memory(memcg, mask, order);
> } else {
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue 30-07-13 01:25:44, Andrew Morton wrote:
> On Tue, 30 Jul 2013 09:45:31 +0200 Michal Hocko wrote:
>
> > On Mon 29-07-13 13:57:43, Andrew Morton wrote:
> > > On Fri, 26 Jul 2013 14:44:29 +0200 Michal Hocko wrote:
> > [...]
> > > > --- a/fs/drop_
ups triggered by the OOM kill
> + * uncharges. Wake any sleepers explicitely.
> + */
> + memcg_oom_recover(memcg);
This will be a noop because memcg is no longer under_oom (you wanted
memcg_wakeup_oom here I guess). Moreover, even the killed wouldn't wake
up anybody for the same reason.
> + }
>
> if (test_thread_flag(TIF_MEMDIE) || fatal_signal_pending(current))
> return false;
> --
> 1.8.3.2
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Mon 29-07-13 17:20:01, Peter Zijlstra wrote:
> On Mon, Jul 29, 2013 at 04:53:08PM +0200, Michal Hocko wrote:
> > Peter, for you context the lockdep splat has been reported
> > here: https://lkml.org/lkml/2013/7/17/381
> >
> > Minchan has proposed to workaround it by
deadlocks on unrelated mappings.
Reported-by: Dave Jones
Signed-off-by: Michal Hocko
---
fs/hugetlbfs/inode.c | 8
1 file changed, 8 insertions(+)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index a3f868a..230533d 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@
On Tue 30-07-13 07:39:56, Andrew Morton wrote:
> On Tue, 30 Jul 2013 14:55:25 +0200 Michal Hocko wrote:
>
> > > > I am OK with that but can we use a top bit instead. Maybe we never have
> > > > other entities to drop in the future but it would be better to
On Tue 30-07-13 10:32:28, Johannes Weiner wrote:
> On Tue, Jul 30, 2013 at 04:09:13PM +0200, Michal Hocko wrote:
> > On Fri 26-07-13 17:28:09, Johannes Weiner wrote:
[...]
> > > } else {
> > > schedule();
> > > + mem_cgroup_unmark_under_oom
On Tue 30-07-13 16:58:34, Peter Zijlstra wrote:
> On Tue, Jul 30, 2013 at 04:46:00PM +0200, Michal Hocko wrote:
[...]
> > +/*
> > + * Now, reclaim path never holds hugetlbfs_inode->i_mmap_mutex while it
> > could
> > + * hold normal inode->i_mmap_mutex so
601 - 700 of 11648 matches
Mail list logo
