On 2015/9/9 2:12, Sergey Dyasly wrote:
> On 08.09.2015 5:45, Zhang Zhen wrote:
>> The arch-specific IOREMAP_MAX_ORDER is introduced in
>> commit: ff0daca([ARM] Add section support to ioremap) and
>> commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()).
On 2015/9/9 2:12, Sergey Dyasly wrote:
> On 08.09.2015 5:45, Zhang Zhen wrote:
>> The arch-specific IOREMAP_MAX_ORDER is introduced in
>> commit: ff0daca([ARM] Add section support to ioremap) and
>> commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()).
ed using the usual 4K pages.
In most cases without !SMP && !LPAE, the big alignment cause high fragmentation
issue in vmalloc area.
Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case,
otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h.
Signed-off-b
ed using the usual 4K pages.
In most cases without !SMP && !LPAE, the big alignment cause high fragmentation
issue in vmalloc area.
Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case,
otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h.
S
Currently we have many duplicates in definitions of hugetlb_prefault_arch_hook.
In all architectures this function is empty.
Signed-off-by: Zhang Zhen
---
arch/arm/include/asm/hugetlb.h | 4
arch/arm64/include/asm/hugetlb.h | 4
arch/ia64/include/asm/hugetlb.h| 4
arch
Currently we have many duplicates in definitions of hugetlb_prefault_arch_hook.
In all architectures this function is empty.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
arch/arm/include/asm/hugetlb.h | 4
arch/arm64/include/asm/hugetlb.h | 4
arch/ia64/include/asm
Currently we have many duplicates in definitions of huge_pmd_unshare.
In all architectures this function just returns 0 when
CONFIG_ARCH_WANT_HUGE_PMD_SHARE is N.
This patch put the default implementation in mm/hugetlb.c and lets
these architecture use the common code.
Signed-off-by: Zhang Zhen
Currently we have many duplicates in definitions of huge_pmd_unshare.
In all architectures this function just returns 0 when
CONFIG_ARCH_WANT_HUGE_PMD_SHARE is N.
This patch put the default implementation in mm/hugetlb.c and lets
these architecture use the common code.
Signed-off-by: Zhang Zhen
ot; ; fi
WARN: No /proc/self/uid_map exist, test skipped.
make[1]: Leaving directory `/opt/kernel/tools/testing/selftests/mount'
make: Leaving directory `/opt/kernel/tools/testing/selftests'
Change v1 -> v2:
- fix syntax error when run kselftest_install.sh
Signed-off-by: Zhang Zhen
---
tools/t
On 2015/4/3 2:56, Eric W. Biederman wrote:
> Zhang Zhen writes:
>
>> Without this patch, if /proc/self/uid_map is not exist,
>> the mount test case will fail and no any prompting.
>
> The intent was not to fail if /proc/self/uid_map is missing but to skip
> the test b
ols/testing/selftests'
Signed-off-by: Zhang Zhen
---
tools/testing/selftests/mount/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mount/Makefile
b/tools/testing/selftests/mount/Makefile
index a5b367f..b3266db 100644
--- a/tools/test
/testing/selftests'
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
tools/testing/selftests/mount/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mount/Makefile
b/tools/testing/selftests/mount/Makefile
index a5b367f..b3266db
On 2015/4/3 2:56, Eric W. Biederman wrote:
Zhang Zhen zhenzhang.zh...@huawei.com writes:
Without this patch, if /proc/self/uid_map is not exist,
the mount test case will fail and no any prompting.
The intent was not to fail if /proc/self/uid_map is missing but to skip
the test because
: No /proc/self/uid_map exist, test skipped.
make[1]: Leaving directory `/opt/kernel/tools/testing/selftests/mount'
make: Leaving directory `/opt/kernel/tools/testing/selftests'
Change v1 - v2:
- fix syntax error when run kselftest_install.sh
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
tools
This patch includes the mount test binaries into the .gitignore
file listing in their respective directories. This will make sure
that git ignores all of these test binaries when displaying status.
Signed-off-by: Zhang Zhen
---
tools/testing/selftests/mount/.gitignore | 1 +
1 file changed, 1
This patch includes the mount test binaries into the .gitignore
file listing in their respective directories. This will make sure
that git ignores all of these test binaries when displaying status.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
tools/testing/selftests/mount/.gitignore
On 2015/3/10 21:25, Peter Hurley wrote:
> On 03/09/2015 10:47 PM, Tim Kryger wrote:
>> The current workaround of clearing fifos and retrying a fixed number
>> of times isn't ideal but I'm not sure what else can be done given the
>> way this hardware works.
>
> But hanging the machine is not an
On 2015/3/10 21:25, Peter Hurley wrote:
On 03/09/2015 10:47 PM, Tim Kryger wrote:
The current workaround of clearing fifos and retrying a fixed number
of times isn't ideal but I'm not sure what else can be done given the
way this hardware works.
But hanging the machine is not an acceptable
On 2015/3/10 10:47, Tim Kryger wrote:
> On Mon, Mar 9, 2015 at 8:05 AM, Alan Cox wrote:
>
>> Ah no - I meant what is their official software workaround for existing
>> parts with the bug ? Presumably they have an errata document that
>> discusses this and the correct methods they recommend to
On 2015/3/9 16:53, Greg KH wrote:
> On Mon, Mar 09, 2015 at 04:41:00PM +0800, Zhang Zhen wrote:
>> On 2015/3/9 16:22, Greg KH wrote:
>>> On Mon, Mar 09, 2015 at 03:42:30PM +0800, Zhang Zhen wrote:
>>>> drivers/tty/serial/8250/8250_core.c: In function
>>>>
On 2015/3/9 16:22, Greg KH wrote:
> On Mon, Mar 09, 2015 at 03:42:30PM +0800, Zhang Zhen wrote:
>> drivers/tty/serial/8250/8250_core.c: In function ‘serial8250_console_write’:
>> drivers/tty/serial/8250/8250_core.c:3244: warning: ‘flags’ may be used u
>> unitialized in this
drivers/tty/serial/8250/8250_core.c: In function ‘serial8250_console_write’:
drivers/tty/serial/8250/8250_core.c:3244: warning: ‘flags’ may be used u
unitialized in this function
Signed-off-by: Zhang Zhen
---
drivers/tty/serial/8250/8250_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 2015/3/10 10:47, Tim Kryger wrote:
On Mon, Mar 9, 2015 at 8:05 AM, Alan Cox a...@linux.intel.com wrote:
Ah no - I meant what is their official software workaround for existing
parts with the bug ? Presumably they have an errata document that
discusses this and the correct methods they
On 2015/3/9 16:53, Greg KH wrote:
On Mon, Mar 09, 2015 at 04:41:00PM +0800, Zhang Zhen wrote:
On 2015/3/9 16:22, Greg KH wrote:
On Mon, Mar 09, 2015 at 03:42:30PM +0800, Zhang Zhen wrote:
drivers/tty/serial/8250/8250_core.c: In function
‘serial8250_console_write’:
drivers/tty/serial/8250
On 2015/3/9 16:22, Greg KH wrote:
On Mon, Mar 09, 2015 at 03:42:30PM +0800, Zhang Zhen wrote:
drivers/tty/serial/8250/8250_core.c: In function ‘serial8250_console_write’:
drivers/tty/serial/8250/8250_core.c:3244: warning: ‘flags’ may be used u
unitialized in this function
Signed-off
drivers/tty/serial/8250/8250_core.c: In function ‘serial8250_console_write’:
drivers/tty/serial/8250/8250_core.c:3244: warning: ‘flags’ may be used u
unitialized in this function
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
drivers/tty/serial/8250/8250_core.c | 2 +-
1 file changed
Hi,
I'm testing 4.0-rc1 kernel on my board with 8250 Designware UART.(ARM
Cortex-a15 single core).
I found if serial is busy and writes to the LCR failed after tried 1000
times.
The kernel will hung up.
The system boot success after changed from:
95
Hi,
I'm testing 4.0-rc1 kernel on my board with 8250 Designware UART.(ARM
Cortex-a15 single core).
I found if serial is busy and writes to the LCR failed after tried 1000
times.
The kernel will hung up.
The system boot success after changed from:
95
Hi Andrew Morton,
I noticed there is no a git tree about notify, and i don't know which tree this
patch should be included in.
Can you include this patch in your git tree?
Best regards!
On 2015/2/5 22:49, Jan Kara wrote:
> On Wed 04-02-15 11:01:56, Zhang Zhen wrote:
>> The inotify inte
Hi Andrew Morton,
I noticed there is no a git tree about notify, and i don't know which tree this
patch should be included in.
Can you include this patch in your git tree?
Best regards!
On 2015/2/5 22:49, Jan Kara wrote:
On Wed 04-02-15 11:01:56, Zhang Zhen wrote:
The inotify interface has
off-by: Zhang Zhen
---
Documentation/filesystems/inotify.txt | 197 +-
1 file changed, 3 insertions(+), 194 deletions(-)
diff --git a/Documentation/filesystems/inotify.txt
b/Documentation/filesystems/inotify.txt
index cfd0271..51f61db 100644
--- a/Documentation/filesyst
-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
Documentation/filesystems/inotify.txt | 197 +-
1 file changed, 3 insertions(+), 194 deletions(-)
diff --git a/Documentation/filesystems/inotify.txt
b/Documentation/filesystems/inotify.txt
index cfd0271..51f61db 100644
e inotify_init1 system call is missing.
>
> Zhang suggests to drop sections (iii) and (iv) as they are obsolete
> since 2010.
>
> Shouldn't we drop the whole file?
>
Yeah, i agree.
Thanks!
> Best regards
>
> Heinrich Schuchardt
>
> On 27.01.2015 13:45, Z
The inotify kernel interface was removed by Eric Paris
in this commit: 2dfc1ca inotify: remove inotify in
kernel interface.
Signed-off-by: Zhang Zhen
---
Documentation/filesystems/inotify.txt | 120 +-
1 file changed, 2 insertions(+), 118 deletions(-)
diff --git
call is missing.
Zhang suggests to drop sections (iii) and (iv) as they are obsolete
since 2010.
Shouldn't we drop the whole file?
Yeah, i agree.
Thanks!
Best regards
Heinrich Schuchardt
On 27.01.2015 13:45, Zhang Zhen wrote:
The inotify kernel interface was removed by Eric Paris
The inotify kernel interface was removed by Eric Paris
in this commit: 2dfc1ca inotify: remove inotify in
kernel interface.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
Documentation/filesystems/inotify.txt | 120 +-
1 file changed, 2 insertions
On 2015/1/22 4:06, Paul E. McKenney wrote:
> On Wed, Jan 21, 2015 at 10:10:51AM -0500, Don Zickus wrote:
>> On Wed, Jan 21, 2015 at 10:26:27AM +0800, Zhang Zhen wrote:
>>>> This may not cause other problems but what happens if you comment out the
>>>>
On 2015/1/21 18:16, Paul E. McKenney wrote:
> On Wed, Jan 21, 2015 at 05:05:50PM +0800, Zhang Zhen wrote:
>> On 2015/1/21 15:02, Paul E. McKenney wrote:
>>> On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
>>>> On 2015/1/21 11:13, Zhang Zhen wrote:
>&g
On 2015/1/21 15:02, Paul E. McKenney wrote:
> On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
>> On 2015/1/21 11:13, Zhang Zhen wrote:
>>> On 2015/1/21 10:26, Zhang Zhen wrote:
>>>> On 2015/1/20 23:25, Don Zickus wrote:
>
> [ . . . ]
>
>
On 2015/1/22 4:06, Paul E. McKenney wrote:
On Wed, Jan 21, 2015 at 10:10:51AM -0500, Don Zickus wrote:
On Wed, Jan 21, 2015 at 10:26:27AM +0800, Zhang Zhen wrote:
This may not cause other problems but what happens if you comment out the
'touch_softlockup_watchdog' from the touch_nmi_watchdog
On 2015/1/21 18:16, Paul E. McKenney wrote:
On Wed, Jan 21, 2015 at 05:05:50PM +0800, Zhang Zhen wrote:
On 2015/1/21 15:02, Paul E. McKenney wrote:
On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
On 2015/1/21 11:13, Zhang Zhen wrote:
On 2015/1/21 10:26, Zhang Zhen wrote:
On 2015
On 2015/1/21 15:02, Paul E. McKenney wrote:
On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
On 2015/1/21 11:13, Zhang Zhen wrote:
On 2015/1/21 10:26, Zhang Zhen wrote:
On 2015/1/20 23:25, Don Zickus wrote:
[ . . . ]
Sorry, i made a mistake, the log above is based on v3.10.63
On 2015/1/21 15:02, Paul E. McKenney wrote:
> On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
>> On 2015/1/21 11:13, Zhang Zhen wrote:
>>> On 2015/1/21 10:26, Zhang Zhen wrote:
>>>> On 2015/1/20 23:25, Don Zickus wrote:
>
> [ . . . ]
>
>
On 2015/1/21 11:13, Zhang Zhen wrote:
> On 2015/1/21 10:26, Zhang Zhen wrote:
>> On 2015/1/20 23:25, Don Zickus wrote:
>>> On Tue, Jan 20, 2015 at 11:09:19AM +0800, Zhang Zhen wrote:
>>>>
>>>>> Of course back then, touch_nmi_watchdog touched all cpus.
On 2015/1/21 10:26, Zhang Zhen wrote:
> On 2015/1/20 23:25, Don Zickus wrote:
>> On Tue, Jan 20, 2015 at 11:09:19AM +0800, Zhang Zhen wrote:
>>>
>>>> Of course back then, touch_nmi_watchdog touched all cpus. So a problem
>>>> like this was masked. I
On 2015/1/20 23:25, Don Zickus wrote:
> On Tue, Jan 20, 2015 at 11:09:19AM +0800, Zhang Zhen wrote:
>>
>>> Of course back then, touch_nmi_watchdog touched all cpus. So a problem
>>> like this was masked. I believe this upstream commit 62572e29bc53, solved
>>>
On 2015/1/20 23:25, Don Zickus wrote:
On Tue, Jan 20, 2015 at 11:09:19AM +0800, Zhang Zhen wrote:
Of course back then, touch_nmi_watchdog touched all cpus. So a problem
like this was masked. I believe this upstream commit 62572e29bc53, solved
the problem.
Thanks for your suggestion
On 2015/1/21 10:26, Zhang Zhen wrote:
On 2015/1/20 23:25, Don Zickus wrote:
On Tue, Jan 20, 2015 at 11:09:19AM +0800, Zhang Zhen wrote:
Of course back then, touch_nmi_watchdog touched all cpus. So a problem
like this was masked. I believe this upstream commit 62572e29bc53, solved
On 2015/1/21 11:13, Zhang Zhen wrote:
On 2015/1/21 10:26, Zhang Zhen wrote:
On 2015/1/20 23:25, Don Zickus wrote:
On Tue, Jan 20, 2015 at 11:09:19AM +0800, Zhang Zhen wrote:
Of course back then, touch_nmi_watchdog touched all cpus. So a problem
like this was masked. I believe this upstream
On 2015/1/21 15:02, Paul E. McKenney wrote:
On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
On 2015/1/21 11:13, Zhang Zhen wrote:
On 2015/1/21 10:26, Zhang Zhen wrote:
On 2015/1/20 23:25, Don Zickus wrote:
[ . . . ]
Sorry, i made a mistake, the log above is based on v3.10.63
On 2015/1/19 19:09, Paul E. McKenney wrote:
> On Mon, Jan 19, 2015 at 05:04:29PM +0800, Zhang Zhen wrote:
>> On 2015/1/19 16:42, Paul E. McKenney wrote:
>>> On Mon, Jan 19, 2015 at 04:07:15PM +0800, Zhang Zhen wrote:
>>>> Hi,
>>>>
>>>> On my x8
On 2015/1/19 22:06, Don Zickus wrote:
> On Mon, Jan 19, 2015 at 05:04:29PM +0800, Zhang Zhen wrote:
>>>
>>> Did you really intend to acquire the same spinlock twice in a row,
>>> forcing a self-deadlock? If not, I of course suggest changing the second
>
On 2015/1/19 16:42, Paul E. McKenney wrote:
> On Mon, Jan 19, 2015 at 04:07:15PM +0800, Zhang Zhen wrote:
>> Hi,
>>
>> On my x86_64 qemu virtual machine, RCU CPU stall console spews may
>> lead to soft lockup disabled.
>>
>> If softlockup_thresh > rc
Hi,
On my x86_64 qemu virtual machine, RCU CPU stall console spews may
lead to soft lockup disabled.
If softlockup_thresh > rcu_cpu_stall_timeout (softlockup_thresh = 2 *
watchdog_thresh):
/ #
/ # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
21
/ # echo 60 >
On 2015/1/19 19:09, Paul E. McKenney wrote:
On Mon, Jan 19, 2015 at 05:04:29PM +0800, Zhang Zhen wrote:
On 2015/1/19 16:42, Paul E. McKenney wrote:
On Mon, Jan 19, 2015 at 04:07:15PM +0800, Zhang Zhen wrote:
Hi,
On my x86_64 qemu virtual machine, RCU CPU stall console spews may
lead to soft
On 2015/1/19 22:06, Don Zickus wrote:
On Mon, Jan 19, 2015 at 05:04:29PM +0800, Zhang Zhen wrote:
Did you really intend to acquire the same spinlock twice in a row,
forcing a self-deadlock? If not, I of course suggest changing the second
spin_lock() to spin_unlock().
Yes, i acquire
Hi,
On my x86_64 qemu virtual machine, RCU CPU stall console spews may
lead to soft lockup disabled.
If softlockup_thresh rcu_cpu_stall_timeout (softlockup_thresh = 2 *
watchdog_thresh):
/ #
/ # busybox cat /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
21
/ # echo 60
On 2015/1/19 16:42, Paul E. McKenney wrote:
On Mon, Jan 19, 2015 at 04:07:15PM +0800, Zhang Zhen wrote:
Hi,
On my x86_64 qemu virtual machine, RCU CPU stall console spews may
lead to soft lockup disabled.
If softlockup_thresh rcu_cpu_stall_timeout (softlockup_thresh = 2 *
watchdog_thresh
The inotify kernel interface was removed by Eric Paris
in this commit: 2dfc1ca inotify: remove inotify in
kernel interface.
Signed-off-by: Zhang Zhen
---
Documentation/filesystems/inotify.txt | 120 +-
1 file changed, 2 insertions(+), 118 deletions(-)
diff --git
Hi,
I try to use inotify in kernel module according to
Documentation/filesystems/inotify.txt,
but i found inotify was reimplemented in this commit 63c882a (inotify:
reimplement inotify using fsnotify)
and the document has been expired.
Now how we can monitor
Hi,
I try to use inotify in kernel module according to
Documentation/filesystems/inotify.txt,
but i found inotify was reimplemented in this commit 63c882a (inotify:
reimplement inotify using fsnotify)
and the document has been expired.
Now how we can monitor
The inotify kernel interface was removed by Eric Paris
in this commit: 2dfc1ca inotify: remove inotify in
kernel interface.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
Documentation/filesystems/inotify.txt | 120 +-
1 file changed, 2 insertions
On 2014/11/12 11:16, Yasuaki Ishimatsu wrote:
> (2014/11/11 18:13), Zhang Zhen wrote:
>> The start_pfn can be obtained directly by
>> phys_index << PFN_SECTION_SHIFT.
>>
>> Signed-off-by: Zhang Zhen
>> ---
>
> The patch looks good to me b
The start_pfn can be obtained directly by
phys_index << PFN_SECTION_SHIFT.
Signed-off-by: Zhang Zhen
---
drivers/base/memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7c5d871..85be040 100644
--- a/driver
The start_pfn can be obtained directly by
phys_index PFN_SECTION_SHIFT.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
drivers/base/memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7c5d871..85be040
On 2014/11/12 11:16, Yasuaki Ishimatsu wrote:
(2014/11/11 18:13), Zhang Zhen wrote:
The start_pfn can be obtained directly by
phys_index PFN_SECTION_SHIFT.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
The patch looks good to me but I want you to write a purpose of the patch
memory5/valid_zones: Normal
memory6/valid_zones: Normal Movable
memory7/valid_zones: Movable Normal
memory8/valid_zones: Movable
Signed-off-by: Zhang Zhen
---
Documentation/ABI/testing/sysfs-devices-memory | 8
Documentation/memory-hotplug.txt | 13
|
+-+-+-+
In this case, the check can't guarantee that this is "the last
block of memory".
The check of ZONE_MOVABLE has the same problem.
Signed-off-by: Zhang Zhen
---
drivers/base/memory.c | 36 ++--
1 file changed, 6 insertions(+), 30
|
+-+-+-+
In this case, the check can't guarantee that this is the last
block of memory.
The check of ZONE_MOVABLE has the same problem.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
drivers/base/memory.c | 36 ++--
1 file changed, 6 insertions
memory5/valid_zones: Normal
memory6/valid_zones: Normal Movable
memory7/valid_zones: Movable Normal
memory8/valid_zones: Movable
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
Documentation/ABI/testing/sysfs-devices-memory | 8
Documentation/memory
On 2014/8/26 18:23, Yasuaki Ishimatsu wrote:
> (2014/08/26 18:57), Zhang Zhen wrote:
>> As Yasuaki Ishimatsu described the check here is not enough
>> if memory has hole as follows:
>>
>> PFN 0x00 0xd0
alid_zones: Movable
Signed-off-by: Zhang Zhen
---
Documentation/ABI/testing/sysfs-devices-memory | 8 ++---
Documentation/memory-hotplug.txt | 4 +--
drivers/base/memory.c | 42 ++
3 files changed, 15 insertions(+), 39 deletions(-)
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
Documentation/ABI/testing/sysfs-devices-memory | 8 ++---
Documentation/memory-hotplug.txt | 4 +--
drivers/base/memory.c | 42 ++
3 files changed, 15 insertions(+), 39
On 2014/8/26 18:23, Yasuaki Ishimatsu wrote:
(2014/08/26 18:57), Zhang Zhen wrote:
As Yasuaki Ishimatsu described the check here is not enough
if memory has hole as follows:
PFN 0x00 0xd0 0xe0 0xf0
On 2014/8/23 6:16, Andrew Morton wrote:
> On Mon, 18 Aug 2014 11:25:36 +0800 Zhang Zhen
> wrote:
>
>> On 2014/8/16 5:37, Toshi Kani wrote:
>>> On Wed, 2014-08-13 at 12:10 +0800, Zhang Zhen wrote:
>>>> Currently memory-hotplug has two limits:
>>>&g
On 2014/8/23 6:16, Andrew Morton wrote:
On Mon, 18 Aug 2014 11:25:36 +0800 Zhang Zhen zhenzhang.zh...@huawei.com
wrote:
On 2014/8/16 5:37, Toshi Kani wrote:
On Wed, 2014-08-13 at 12:10 +0800, Zhang Zhen wrote:
Currently memory-hotplug has two limits:
1. If the memory block
On 2014/8/18 14:11, Yasuaki Ishimatsu wrote:
> (2014/08/13 13:10), Zhang Zhen wrote:
>> Currently memory-hotplug has two limits:
>> 1. If the memory block is in ZONE_NORMAL, you can change it to
>> ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
>
On 2014/8/18 14:11, Yasuaki Ishimatsu wrote:
(2014/08/13 13:10), Zhang Zhen wrote:
Currently memory-hotplug has two limits:
1. If the memory block is in ZONE_NORMAL, you can change it to
ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
2. If the memory block
On 2014/8/19 5:48, David Rientjes wrote:
> On Wed, 13 Aug 2014, Zhang Zhen wrote:
>
>> Currently memory-hotplug has two limits:
>> 1. If the memory block is in ZONE_NORMAL, you can change it to
>> ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
&
On 2014/8/19 5:48, David Rientjes wrote:
On Wed, 13 Aug 2014, Zhang Zhen wrote:
Currently memory-hotplug has two limits:
1. If the memory block is in ZONE_NORMAL, you can change it to
ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
2. If the memory block
On 2014/8/16 5:37, Toshi Kani wrote:
> On Wed, 2014-08-13 at 12:10 +0800, Zhang Zhen wrote:
>> Currently memory-hotplug has two limits:
>> 1. If the memory block is in ZONE_NORMAL, you can change it to
>> ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE
On 2014/8/16 5:37, Toshi Kani wrote:
On Wed, 2014-08-13 at 12:10 +0800, Zhang Zhen wrote:
Currently memory-hotplug has two limits:
1. If the memory block is in ZONE_NORMAL, you can change it to
ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
2. If the memory block
to ZONE_NORMAL.
With this patch, we can easy to know a memory block can be onlined to
which zone, and don't need to know the above two limits.
Updated the related Documentation.
Change v1 -> v2:
- optimize the implementation following Dave Hansen's suggestion
Signed-off-by: Zhang Z
to ZONE_NORMAL.
With this patch, we can easy to know a memory block can be onlined to
which zone, and don't need to know the above two limits.
Updated the related Documentation.
Change v1 - v2:
- optimize the implementation following Dave Hansen's suggestion
Signed-off-by: Zhang Zhen zhenzhang.zh
move the end_pfn and use start_pfn + nr_pages in the conditional.
Signed-off-by: Zhang Zhen
Acked-by: David Rientjes
---
arch/x86/mm/init_64.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index df1a992
move the end_pfn and use start_pfn + nr_pages in the conditional.
Signed-off-by: Zhang Zhen
---
arch/x86/mm/init_64.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index df1a992..d16368e 100644
--- a/arch/x86/mm
On 2014/7/29 17:18, David Rientjes wrote:
> On Tue, 29 Jul 2014, Zhang Zhen wrote:
>
>>>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>>>> index df1a992..fd7bd6b 100644
>>>> --- a/arch/x86/mm/init_64.c
>>>> +++ b/arch/x
On 2014/7/29 15:53, David Rientjes wrote:
> On Tue, 29 Jul 2014, Zhang Zhen wrote:
>
>> Commit ea0854170c95245a258b386c7a9314399c949fe0 added a fuction
>
> This would normally be written as
>
> Commit ea0854170c95 ("memory hotplug: fix a bug on /dev/mem for
v1->v2:
- according to Dave Hansen and David Rientjes's suggestions modified
update_end_of_memory_vars().
Signed-off-by: Zhang Zhen
---
arch/x86/mm/init_64.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init
On 2014/7/29 7:24, Dave Hansen wrote:
> On 07/28/2014 04:12 PM, David Rientjes wrote:
>> I agree, but I'm not sure the suggestion is any better than the patch. I
>> think it would be better to just figure out whether anything needs to be
>> updated in the caller and then call a generic
On 2014/7/29 7:24, Dave Hansen wrote:
On 07/28/2014 04:12 PM, David Rientjes wrote:
I agree, but I'm not sure the suggestion is any better than the patch. I
think it would be better to just figure out whether anything needs to be
updated in the caller and then call a generic function.
So
v1-v2:
- according to Dave Hansen and David Rientjes's suggestions modified
update_end_of_memory_vars().
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
arch/x86/mm/init_64.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64
On 2014/7/29 15:53, David Rientjes wrote:
On Tue, 29 Jul 2014, Zhang Zhen wrote:
Commit ea0854170c95245a258b386c7a9314399c949fe0 added a fuction
This would normally be written as
Commit ea0854170c95 (memory hotplug: fix a bug on /dev/mem for 64-bit
kernels) ...
ok
On 2014/7/29 17:18, David Rientjes wrote:
On Tue, 29 Jul 2014, Zhang Zhen wrote:
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index df1a992..fd7bd6b 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -673,15 +673,11 @@ void __init paging_init(void)
* After
start_pfn + nr_pages in the conditional.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
arch/x86/mm/init_64.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index df1a992..d16368e 100644
--- a/arch
start_pfn + nr_pages in the conditional.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
Acked-by: David Rientjes rient...@google.com
---
arch/x86/mm/init_64.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64
Commit ea0854170c95245a258b386c7a9314399c949fe0 added a fuction
update_end_of_memory_vars() to update high_memory, max_pfn and
max_low_pfn.
Here modified the function(added an argument to show add or remove).
And call it in arch_remove_memory() to update these variables too.
Signed-off-by: Zhang
Commit ea0854170c95245a258b386c7a9314399c949fe0 added a fuction
update_end_of_memory_vars() to update high_memory, max_pfn and
max_low_pfn.
Here modified the function(added an argument to show add or remove).
And call it in arch_remove_memory() to update these variables too.
Signed-off-by: Zhang
On 2014/7/25 10:39, Zhang Zhen wrote:
> On 2014/7/25 1:59, Dave Hansen wrote:
>> On 07/24/2014 12:41 AM, Zhang Zhen wrote:
>>> Currently memory-hotplug has two limits:
>>> 1. If the memory block is in ZONE_NORMAL, you can change it to
>>> ZONE_MOVABLE, bu
On 2014/7/25 10:39, Zhang Zhen wrote:
On 2014/7/25 1:59, Dave Hansen wrote:
On 07/24/2014 12:41 AM, Zhang Zhen wrote:
Currently memory-hotplug has two limits:
1. If the memory block is in ZONE_NORMAL, you can change it to
ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE
1 - 100 of 110 matches
Mail list logo
