an independent function to calculate page
> address from thread_info one.
>
> Suggested-by: Sungjinn Chung
> Signed-off-by: Jungseok Lee
> Cc: KOSAKI Motohiro
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> kernel/fork.c | 7 ++-
> 1 file changed, 6 insertions(+
, introduces an independent function to calculate page
address from thread_info one.
Suggested-by: Sungjinn Chung baram...@gmail.com
Signed-off-by: Jungseok Lee jungseokle...@gmail.com
Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: linux-arm-ker...@lists.infradead.org
---
kernel/fork.c | 7
atch. I would like to see the mmap man page adjusted
> to make note of this behavior as well.
This is just a bug fix and I never think this has large risk. But
caution, we might revert immediately
if this patch arise some regression even if it's come from broken
application code.
Acked-by: KOS
arise some regression even if it's come from broken
application code.
Acked-by: KOSAKI Motohiro kosaki.motoh...@gmail.com
--
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
On Fri, Dec 12, 2014 at 11:05 AM, KOSAKI Motohiro
wrote:
> On Fri, Dec 12, 2014 at 5:19 AM, Lai Jiangshan wrote:
>> A pwq bound to a specified node might be last long or even forever after
>> the node was offline. Especially when this pwq has some back-to-back work
>>
On Fri, Dec 12, 2014 at 5:19 AM, Lai Jiangshan wrote:
> A pwq bound to a specified node might be last long or even forever after
> the node was offline. Especially when this pwq has some back-to-back work
> items which requeue themselves and cause the pwq can't quit.
>
> This kinds of pwqs will
On Fri, Dec 12, 2014 at 5:19 AM, Lai Jiangshan la...@cn.fujitsu.com wrote:
A pwq bound to a specified node might be last long or even forever after
the node was offline. Especially when this pwq has some back-to-back work
items which requeue themselves and cause the pwq can't quit.
This
On Fri, Dec 12, 2014 at 11:05 AM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
On Fri, Dec 12, 2014 at 5:19 AM, Lai Jiangshan la...@cn.fujitsu.com wrote:
A pwq bound to a specified node might be last long or even forever after
the node was offline. Especially when this pwq has some back
> I agree that reporting the amount of shared pages in that historically fashion
> might not be interesting for userspace tools resorting to sysinfo(2),
> nowadays.
>
> OTOH, our documentation implies we do return shared memory there, and FWIW,
> considering the other places we do export the
I agree that reporting the amount of shared pages in that historically fashion
might not be interesting for userspace tools resorting to sysinfo(2),
nowadays.
OTOH, our documentation implies we do return shared memory there, and FWIW,
considering the other places we do export the shared
>> This change hwpoison and migration tag number. maybe ok, maybe not.
>
> Though depending on config can't these tag numbers change anyway?
I don't think distro disable any of these.
>> I'd suggest to use younger number than hwpoison.
>> (That's why hwpoison uses younger number than migration)
This change hwpoison and migration tag number. maybe ok, maybe not.
Though depending on config can't these tag numbers change anyway?
I don't think distro disable any of these.
I'd suggest to use younger number than hwpoison.
(That's why hwpoison uses younger number than migration)
So I
On Fri, Apr 4, 2014 at 1:00 AM, Davidlohr Bueso wrote:
> On Thu, 2014-04-03 at 19:39 -0400, KOSAKI Motohiro wrote:
>> On Thu, Apr 3, 2014 at 3:50 PM, Davidlohr Bueso wrote:
>> > On Thu, 2014-04-03 at 21:02 +0200, Manfred Spraul wrote:
>> >> Hi Davidlohr,
>
On Fri, Apr 4, 2014 at 1:00 AM, Davidlohr Bueso davidl...@hp.com wrote:
On Thu, 2014-04-03 at 19:39 -0400, KOSAKI Motohiro wrote:
On Thu, Apr 3, 2014 at 3:50 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Thu, 2014-04-03 at 21:02 +0200, Manfred Spraul wrote:
Hi Davidlohr,
On 04/03/2014
> This change allows Linux to treat shm just as regular anonymous memory.
> One important difference between them, though, is handling out-of-memory
> conditions: as opposed to regular anon memory, the OOM killer will not
> kill processes that are hogging memory through shm, allowing users to
>
On Thu, Apr 3, 2014 at 3:50 PM, Davidlohr Bueso wrote:
> On Thu, 2014-04-03 at 21:02 +0200, Manfred Spraul wrote:
>> Hi Davidlohr,
>>
>> On 04/03/2014 02:20 AM, Davidlohr Bueso wrote:
>> > The default size for shmmax is, and always has been, 32Mb.
>> > Today, in the XXI century, it seems that
On Wed, Apr 2, 2014 at 12:09 PM, Dave Hansen wrote:
> On 04/02/2014 01:56 AM, Li Zhong wrote:
>> I noticed the phys_index and end_phys_index under
>> /sys/devices/system/memory/memoryXXX/ have the same value, e.g.
>> (for the test machine, one memory block has 8 sections, that is
>>
; + if (ns->shm_ctlmax &&
> + (size < SHMMIN || size > ns->shm_ctlmax))
> return -EINVAL;
>
> - if (ns->shm_tot + numpages > ns->shm_ctlall)
> + if (ns->shm_ctlall &&
> + ns->shm_tot +
;
shp = ipc_rcu_alloc(sizeof(*shp));
Looks good.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
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
On Wed, Apr 2, 2014 at 12:09 PM, Dave Hansen dave.han...@intel.com wrote:
On 04/02/2014 01:56 AM, Li Zhong wrote:
I noticed the phys_index and end_phys_index under
/sys/devices/system/memory/memoryXXX/ have the same value, e.g.
(for the test machine, one memory block has 8 sections, that is
On Thu, Apr 3, 2014 at 3:50 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Thu, 2014-04-03 at 21:02 +0200, Manfred Spraul wrote:
Hi Davidlohr,
On 04/03/2014 02:20 AM, Davidlohr Bueso wrote:
The default size for shmmax is, and always has been, 32Mb.
Today, in the XXI century, it seems that
This change allows Linux to treat shm just as regular anonymous memory.
One important difference between them, though, is handling out-of-memory
conditions: as opposed to regular anon memory, the OOM killer will not
kill processes that are hogging memory through shm, allowing users to
>> > Ah-hah, that's interesting info.
>> >
>> > Let's make the default 64GB?
>>
>> 64GB is infinity at that time, but it no longer near infinity today. I like
>> very large or total memory proportional number.
>
> So I still like 0 for unlimited. Nice, clean and much easier to look at
> than
On Tue, Apr 1, 2014 at 5:48 PM, Andrew Morton wrote:
> On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro
> wrote:
>
>> >> > Hmmm so 0 won't really work because it could be weirdly used to disable
>> >> > shm altogether... we cannot go to some negative v
>> > Hmmm so 0 won't really work because it could be weirdly used to disable
>> > shm altogether... we cannot go to some negative value either since we're
>> > dealing with unsigned, and cutting the range in half could also hurt
>> > users that set the limit above that. So I was thinking of simply
On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso wrote:
> On Tue, 2014-04-01 at 15:51 -0400, KOSAKI Motohiro wrote:
>> >> So, I personally like 0 byte per default.
>> >
>> > If by this you mean 0 bytes == unlimited, then I agree. It's less harsh
>>
>> Our middleware engineers has been complaining about this sysctl limit.
>> System administrator need to calculate required sysctl value by making sum
>> of all planned middlewares, and middleware provider needs to write "please
>> calculate systcl param by." in their installation manuals.
>
On Tue, Apr 1, 2014 at 2:31 PM, Davidlohr Bueso wrote:
> On Tue, 2014-04-01 at 14:10 -0400, KOSAKI Motohiro wrote:
>> On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso wrote:
>> > On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
>> >> On Mon, 31 Mar 2014
On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso wrote:
> On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
>> On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso wrote:
>>
>> > On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
>> > > On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso
On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700 Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 16:13 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 15:59:33
On Tue, Apr 1, 2014 at 2:31 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Tue, 2014-04-01 at 14:10 -0400, KOSAKI Motohiro wrote:
On Tue, Apr 1, 2014 at 1:01 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Mon, 2014-03-31 at 17:05 -0700, Andrew Morton wrote:
On Mon, 31 Mar 2014 16:25:32 -0700
Our middleware engineers has been complaining about this sysctl limit.
System administrator need to calculate required sysctl value by making sum
of all planned middlewares, and middleware provider needs to write please
calculate systcl param by. in their installation manuals.
Why aren't
On Tue, Apr 1, 2014 at 5:01 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Tue, 2014-04-01 at 15:51 -0400, KOSAKI Motohiro wrote:
So, I personally like 0 byte per default.
If by this you mean 0 bytes == unlimited, then I agree. It's less harsh
then removing it entirely. So instead
Hmmm so 0 won't really work because it could be weirdly used to disable
shm altogether... we cannot go to some negative value either since we're
dealing with unsigned, and cutting the range in half could also hurt
users that set the limit above that. So I was thinking of simply setting
On Tue, Apr 1, 2014 at 5:48 PM, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 1 Apr 2014 17:41:54 -0400 KOSAKI Motohiro kosaki.motoh...@gmail.com
wrote:
Hmmm so 0 won't really work because it could be weirdly used to disable
shm altogether... we cannot go to some negative value
Ah-hah, that's interesting info.
Let's make the default 64GB?
64GB is infinity at that time, but it no longer near infinity today. I like
very large or total memory proportional number.
So I still like 0 for unlimited. Nice, clean and much easier to look at
than ULONG_MAX. And since we
On Fri, Mar 21, 2014 at 2:17 PM, John Stultz wrote:
> One issue that some potential users were concerned about, was that
> they wanted to ensure that all the pages from one volatile range
> were purged before we purge pages from a different volatile range.
> This would prevent the case where they
Cc: Robert Love
> Cc: Mel Gorman
> Cc: Hugh Dickins
> Cc: Dave Hansen
> Cc: Rik van Riel
> Cc: Dmitry Adamushko
> Cc: Neil Brown
> Cc: Andrea Arcangeli
> Cc: Mike Hommey
> Cc: Taras Glek
> Cc: Jan Kara
> Cc: KOSAKI Motohiro
> Cc: Michel Lespinasse
On Sun, Mar 23, 2014 at 1:26 PM, John Stultz wrote:
> On Sun, Mar 23, 2014 at 10:50 AM, KOSAKI Motohiro
> wrote:
>>> +/**
>>> + * vrange_check_purged_pte - Checks ptes for purged pages
>>> + *
>>> + * Iterates over the ptes in the pmd checkin
> +/**
> + * vrange_check_purged_pte - Checks ptes for purged pages
> + *
> + * Iterates over the ptes in the pmd checking if they have
> + * purged swap entries.
> + *
> + * Sets the vrange_walker.pages_purged to 1 if any were purged.
> + */
> +static int vrange_check_purged_pte(pmd_t *pmd,
Hugh Dickins
> Cc: Dave Hansen
> Cc: Rik van Riel
> Cc: Dmitry Adamushko
> Cc: Neil Brown
> Cc: Andrea Arcangeli
> Cc: Mike Hommey
> Cc: Taras Glek
> Cc: Jan Kara
> Cc: KOSAKI Motohiro
> Cc: Michel Lespinasse
> Cc: Minchan Kim
> Cc: linux...@
ter is invalid
>
> This a simplified implementation which reuses some of the logic
> from Minchan's earlier efforts. So credit to Minchan for his work.
>
> Cc: Andrew Morton
> Cc: Android Kernel Team
> Cc: Johannes Weiner
> Cc: Robert Love
> Cc: Mel Gorman
> C
...@redhat.com
Cc: Mike Hommey m...@glandium.org
Cc: Taras Glek tg...@mozilla.com
Cc: Jan Kara j...@suse.cz
Cc: KOSAKI Motohiro kosaki.motoh...@gmail.com
Cc: Michel Lespinasse wal...@google.com
Cc: Minchan Kim minc...@kernel.org
Cc: linux...@kvack.org linux...@kvack.org
Signed-off-by: John Stultz
...@glandium.org
Cc: Taras Glek tg...@mozilla.com
Cc: Jan Kara j...@suse.cz
Cc: KOSAKI Motohiro kosaki.motoh...@gmail.com
Cc: Michel Lespinasse wal...@google.com
Cc: Minchan Kim minc...@kernel.org
Cc: linux...@kvack.org linux...@kvack.org
Signed-off-by: John Stultz john.stu...@linaro.org
+/**
+ * vrange_check_purged_pte - Checks ptes for purged pages
+ *
+ * Iterates over the ptes in the pmd checking if they have
+ * purged swap entries.
+ *
+ * Sets the vrange_walker.pages_purged to 1 if any were purged.
+ */
+static int vrange_check_purged_pte(pmd_t *pmd, unsigned long
On Sun, Mar 23, 2014 at 1:26 PM, John Stultz john.stu...@linaro.org wrote:
On Sun, Mar 23, 2014 at 10:50 AM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
+/**
+ * vrange_check_purged_pte - Checks ptes for purged pages
+ *
+ * Iterates over the ptes in the pmd checking if they have
aarca...@redhat.com
Cc: Mike Hommey m...@glandium.org
Cc: Taras Glek tg...@mozilla.com
Cc: Jan Kara j...@suse.cz
Cc: KOSAKI Motohiro kosaki.motoh...@gmail.com
Cc: Michel Lespinasse wal...@google.com
Cc: Minchan Kim minc...@kernel.org
Cc: linux...@kvack.org linux...@kvack.org
Signed-off
On Fri, Mar 21, 2014 at 2:17 PM, John Stultz john.stu...@linaro.org wrote:
One issue that some potential users were concerned about, was that
they wanted to ensure that all the pages from one volatile range
were purged before we purge pages from a different volatile range.
This would prevent
>> + /*
>> + * Ensure that the page's data was copied from old one by
>> + * aio_migratepage().
>> + */
>> + smp_rmb();
>> +
>
> smp_read_barrier_depends() is better.
>
> "One could place an A smp_rmb() primitive between the pointer
+ /*
+ * Ensure that the page's data was copied from old one by
+ * aio_migratepage().
+ */
+ smp_rmb();
+
smp_read_barrier_depends() is better.
One could place an A smp_rmb() primitive between the pointer fetch and
On Mon, Feb 24, 2014 at 11:13 AM, Konrad Rzeszutek Wilk
wrote:
> On Sat, Feb 22, 2014 at 11:53:31PM -0800, Steven Noonan wrote:
>> On Fri, Feb 21, 2014 at 12:07 PM, Konrad Rzeszutek Wilk
>> wrote:
>> > On Thu, Feb 20, 2014 at 12:44:15PM -0800, Steven Noonan wrote:
>> >> On Wed, Feb 19, 2014 at
On Mon, Feb 24, 2014 at 11:13 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Sat, Feb 22, 2014 at 11:53:31PM -0800, Steven Noonan wrote:
On Fri, Feb 21, 2014 at 12:07 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Thu, Feb 20, 2014 at 12:44:15PM -0800, Steven Noonan
From: KOSAKI Motohiro
To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
During aio buffer migration, we have a possibility to see the
following call stack.
aio_migratepage [disable interrupt]
migrate_page_copy
clear_page_dirty_for_io
set_page_dirty
> Indeed, good catch. Do we need the same treatment for
> __set_page_dirty_buffers() that can be called by way of
> clear_page_dirty_for_io()?
Indeed. I posted a patch fixed __set_page_dirty() too. plz see
Subject: [PATCH] __set_page_dirty uses spin_lock_irqsave instead of
spin_lock_irq
--
To
From: KOSAKI Motohiro
To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
spin_lock_irqsave is a safer alternative. Luckily, now there is no
caller that has such usage but it would be nice to fix.
Reported-by: David Rientjes rient...@google.com>
Signed-off-by: KOSAKI Motoh
On Tue, Feb 4, 2014 at 11:58 AM, wrote:
> From: KOSAKI Motohiro
>
> To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
> spin_lock_irqsave is a safer alternative. Luckily, now there is no
> caller that has such usage but it would be nice to fix.
>
> Report
On Tue, Feb 4, 2014 at 11:58 AM, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
spin_lock_irqsave is a safer alternative. Luckily, now there is no
caller that has such usage
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
spin_lock_irqsave is a safer alternative. Luckily, now there is no
caller that has such usage but it would be nice to fix.
Reported-by: David Rientjes rient...@google.com
Indeed, good catch. Do we need the same treatment for
__set_page_dirty_buffers() that can be called by way of
clear_page_dirty_for_io()?
Indeed. I posted a patch fixed __set_page_dirty() too. plz see
Subject: [PATCH] __set_page_dirty uses spin_lock_irqsave instead of
spin_lock_irq
--
To
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
To use spin_{un}lock_irq is dangerous if caller disabled interrupt.
During aio buffer migration, we have a possibility to see the
following call stack.
aio_migratepage [disable interrupt]
migrate_page_copy
clear_page_dirty_for_io
From: KOSAKI Motohiro
During aio stress test, we observed the following lockdep warning.
This mean AIO+numa_balancing is currently deadlockable.
The problem is, aio_migratepage disable interrupt, but
__set_page_dirty_nobuffers
unintentionally enable it again.
Generally, all helper function
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
During aio stress test, we observed the following lockdep warning.
This mean AIO+numa_balancing is currently deadlockable.
The problem is, aio_migratepage disable interrupt, but
__set_page_dirty_nobuffers
unintentionally enable it again
Hi Minchan,
On Thu, Jan 2, 2014 at 2:12 AM, Minchan Kim wrote:
> Hey all,
>
> Happy New Year!
>
> I know it's bad timing to send this unfamiliar large patchset for
> review but hope there are some guys with freshed-brain in new year
> all over the world. :)
> And most important thing is that
Hi Minchan,
On Thu, Jan 2, 2014 at 2:12 AM, Minchan Kim minc...@kernel.org wrote:
Hey all,
Happy New Year!
I know it's bad timing to send this unfamiliar large patchset for
review but hope there are some guys with freshed-brain in new year
all over the world. :)
And most important thing
wn
> Cc: "Rafael J. Wysocki"
> Cc: Linn Crosetto
> Cc: Pekka Enberg
> Cc: Yinghai Lu
> Cc: Andrew Morton
> Cc: Toshi Kani
> Cc: Tang Chen
> Cc: Wen Congyang
> Cc: Vivek Goyal
> Cc: kosaki.motoh...@gmail.com
> Cc: dyo...@redhat.com
> Cc: Toshi Ka
On Sun, Jan 12, 2014 at 6:46 PM, Prarit Bhargava wrote:
>
>
> On 01/11/2014 11:35 AM, 7egg...@gmx.de wrote:
>>
>>
>> On Fri, 10 Jan 2014, Prarit Bhargava wrote:
>>
>>> kdump uses memmap=exactmap and mem=X values to configure the memory
>>> mapping for the kdump kernel. If memory is hotadded
On Sun, Jan 12, 2014 at 6:46 PM, Prarit Bhargava pra...@redhat.com wrote:
On 01/11/2014 11:35 AM, 7egg...@gmx.de wrote:
On Fri, 10 Jan 2014, Prarit Bhargava wrote:
kdump uses memmap=exactmap and mem=X values to configure the memory
mapping for the kdump kernel. If memory is hotadded
: Vivek Goyal vgo...@redhat.com
Cc: kosaki.motoh...@gmail.com
Cc: dyo...@redhat.com
Cc: Toshi Kani toshi.k...@hp.com
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
I think we need a knob manually enable mem-hotplug when specify memmap. But
it is another story.
Acked-by: KOSAKI Motohiro
On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal wrote:
> On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote:
>
> [..]
>> > The system then panics and the kdump/kexec kernel boots. During this boot
>> > ACPi is initialized and the kernel (as can be seen above)
>>
>> Which is a bug.
On Thu, Jan 9, 2014 at 10:00 AM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Jan 09, 2014 at 12:00:29AM +0100, Rafael J. Wysocki wrote:
[..]
The system then panics and the kdump/kexec kernel boots. During this boot
ACPi is initialized and the kernel (as can be seen above)
Which is a
On Mon, Jan 6, 2014 at 11:47 AM, Motohiro Kosaki
wrote:
>
>
>> -Original Message-
>> From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus
>> Torvalds
>> Sent: Friday, January 03, 2014 7:18 PM
>> To: Vlastimil Babka
>> Cc: Sasha Levin; Andrew Morton; Wanpeng Li; Michel
On Mon, Jan 6, 2014 at 11:47 AM, Motohiro Kosaki
motohiro.kos...@us.fujitsu.com wrote:
-Original Message-
From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus
Torvalds
Sent: Friday, January 03, 2014 7:18 PM
To: Vlastimil Babka
Cc: Sasha Levin; Andrew Morton;
m(unsigned int filter)
> printk("%lu pages in pagetable cache\n",
> quicklist_total_size());
> #endif
> +#ifdef CONFIG_MEMORY_FAILURE
> + printk("%lu pages hwpoisoned\n", atomic_long_read(_poisoned_pages));
> +#endif
> }
Looks ok.
Acked-by: KO
; Signed-off-by: Frederic Weisbecker
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Oleg Nesterov
> Cc: Kosaki Motohiro
> Cc: Andrew Morton
Looks good to me.
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this list: send the line "unsubsc
Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Kosaki Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Andrew Morton a...@linux-foundation.org
Looks good to me.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from
show_mem(unsigned int filter)
printk(%lu pages in pagetable cache\n,
quicklist_total_size());
#endif
+#ifdef CONFIG_MEMORY_FAILURE
+ printk(%lu pages hwpoisoned\n, atomic_long_read(num_poisoned_pages));
+#endif
}
Looks ok.
Acked-by: KOSAKI Motohiro kosaki.motoh
> @@ -1090,13 +1063,8 @@ void posix_cpu_timer_schedule(struct k_itimer *timer)
> timer->it.cpu.expires = 0;
> goto out_unlock;
> } else if (unlikely(p->exit_state) && thread_group_empty(p)) {
> - /*
> -
@@ -1090,13 +1063,8 @@ void posix_cpu_timer_schedule(struct k_itimer *timer)
timer-it.cpu.expires = 0;
goto out_unlock;
} else if (unlikely(p-exit_state) thread_group_empty(p)) {
- /*
- *
will add the subtle change. CLONE_THREAD doesn't require CLONE_FS, so
> copy_fs() can fail even it the caller doesn't share ->fs with the execing
> thread. And we still need fs->lock to set signal->in_exec, this looks
> a bit strange.
Oops. Yes, this is totally odd. Sorry, we need t
(11/22/2013 3:33 PM), Oleg Nesterov wrote:
> On 11/22, KOSAKI Motohiro wrote:
>>
>> (11/22/2013 12:54 PM), Oleg Nesterov wrote:
>>> We can kill either task->did_exec or PF_FORKNOEXEC, they are
>>> mutually exclusive. The patch kill ->did_exec because
(11/22/2013 3:24 PM), Oleg Nesterov wrote:
> On 11/22, KOSAKI Motohiro wrote:
>>
>> (11/22/2013 12:54 PM), Oleg Nesterov wrote:
>>> next_thread() should be avoided, change check_unsafe_exec()
>>> to use while_each_thread(). This also saves 32 bytes.
>>
>&
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
> Both success/failure paths cleanup bprm->file, we can move this
> code into free_bprm() to simlify and cleanup this logic.
>
> Signed-off-by: Oleg Nesterov
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this list: send the li
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
> fs_struct->in_exec == T means that this ->fs is used by a single
> process (thread group), and one of the treads does do_execve().
>
> To avoid the mt-exec races this code has the following complications:
>
> 1. check_unsafe_exec() returns
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
> next_thread() should be avoided, change check_unsafe_exec()
> to use while_each_thread(). This also saves 32 bytes.
Just curious.
Why it should be avoided? Just for cleaner code? Or is there
serious issue?
--
To unsubscribe from this list: send the
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
> We can kill either task->did_exec or PF_FORKNOEXEC, they are
> mutually exclusive. The patch kill ->did_exec because it has
> a single user.
It's ok.
but,
> - * Auch. Had to add the 'did_exec' flag to conform completely to POSIX.
> - * LBT 04.03.94
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
We can kill either task-did_exec or PF_FORKNOEXEC, they are
mutually exclusive. The patch kill -did_exec because it has
a single user.
It's ok.
but,
- * Auch. Had to add the 'did_exec' flag to conform completely to POSIX.
- * LBT 04.03.94
+ *
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
next_thread() should be avoided, change check_unsafe_exec()
to use while_each_thread(). This also saves 32 bytes.
Just curious.
Why it should be avoided? Just for cleaner code? Or is there
serious issue?
--
To unsubscribe from this list: send the
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
fs_struct-in_exec == T means that this -fs is used by a single
process (thread group), and one of the treads does do_execve().
To avoid the mt-exec races this code has the following complications:
1. check_unsafe_exec() returns -EBUSY if
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
Both success/failure paths cleanup bprm-file, we can move this
code into free_bprm() to simlify and cleanup this logic.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from
(11/22/2013 3:24 PM), Oleg Nesterov wrote:
On 11/22, KOSAKI Motohiro wrote:
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
next_thread() should be avoided, change check_unsafe_exec()
to use while_each_thread(). This also saves 32 bytes.
Just curious.
Why it should be avoided? Just for cleaner
(11/22/2013 3:33 PM), Oleg Nesterov wrote:
On 11/22, KOSAKI Motohiro wrote:
(11/22/2013 12:54 PM), Oleg Nesterov wrote:
We can kill either task-did_exec or PF_FORKNOEXEC, they are
mutually exclusive. The patch kill -did_exec because it has
a single user.
It's ok.
but,
- * Auch. Had
() can fail even it the caller doesn't share -fs with the execing
thread. And we still need fs-lock to set signal-in_exec, this looks
a bit strange.
Oops. Yes, this is totally odd. Sorry, we need to stop off topic discussion.
Anyway
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
I
On Tue, Nov 19, 2013 at 4:49 PM, Andi Kleen wrote:
> Michal Hocko writes:
>>
>> Another option would be to use sysctl values for the top cpuset as a
>> default. But then why not just do it manually without sysctl?
>
> I want to provide an alternative to having to use cpusets to use this,
> that
On Tue, Nov 19, 2013 at 4:49 PM, Andi Kleen a...@firstfloor.org wrote:
Michal Hocko mho...@suse.cz writes:
Another option would be to use sysctl values for the top cpuset as a
default. But then why not just do it manually without sysctl?
I want to provide an alternative to having to use
erformance increase his test case.
>
> Reported-by: Larry Woodman
> Suggested-by: Paul Turner
> Signed-off-by: Peter Zijlstra
> Cc: KOSAKI Motohiro
> Cc: Linus Torvalds
> Cc: Andrew Morton
> Link:
> http://lkml.kernel.org/r/2013172925.gg26...@twins.programmi
.
Reported-by: Larry Woodman lwood...@redhat.com
Suggested-by: Paul Turner p...@google.com
Signed-off-by: Peter Zijlstra pet...@infradead.org
Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Andrew Morton a...@linux-foundation.org
Link
>> I'm slightly surprised this cache makes 15% hit. Which application
>> get a benefit? You listed a lot of applications, but I'm not sure
>> which is highly depending on largest vma.
>
> Well I chose the largest vma because it gives us a greater chance of
> being already cached when we do the
I'm slightly surprised this cache makes 15% hit. Which application
get a benefit? You listed a lot of applications, but I'm not sure
which is highly depending on largest vma.
Well I chose the largest vma because it gives us a greater chance of
being already cached when we do the lookup for
(11/1/13 4:17 PM), Davidlohr Bueso wrote:
While caching the last used vma already does a nice job avoiding
having to iterate the rbtree in find_vma, we can improve. After
studying the hit rate on a load of workloads and environments,
it was seen that it was around 45-50% - constant for a
(11/1/13 3:54 AM), Yuanhan Liu wrote:
> Patch 1 turns locking the anon_vma's root to locking itself to let it be
> a per anon_vma lock, which would reduce contentions.
>
> In the same time, lock range becomes quite small then, which is bascially
> a call of anon_vma_interval_tree_insert(). Patch
1 - 100 of 949 matches
Mail list logo
