-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
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
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/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/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
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 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 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
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/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
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
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
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
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
/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
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 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
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
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()).
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
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
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
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
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(-)
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
|
+-+-+-+
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
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
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
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
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
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
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
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()).
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
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
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 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/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 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/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 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 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 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
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 > rc
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
>>>>
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
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,
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
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 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
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/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
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/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/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
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,
Now we can hot-add memory by
% echo start_address_of_new_memory /sys/devices/system/memory/probe
Then, [start_address_of_new_memory, start_address_of_new_memory +
memory_block_size] memory range is hot-added.
But we can only hot-add *one section one time* by this way.
Whether we can add
On 2014/6/12 6:08, David Rientjes wrote:
On Wed, 11 Jun 2014, Zhang Zhen wrote:
Hi,
Now we can hot-add memory by
% echo start_address_of_new_memory /sys/devices/system/memory/probe
Then, [start_address_of_new_memory, start_address_of_new_memory +
memory_block_size] memory range is hot
On 2014/6/12 15:07, David Rientjes wrote:
On Thu, 12 Jun 2014, Zhang Zhen wrote:
% echo start_address_of_new_memory count_of_sections
/sys/devices/system/memory/probe
Then, [start_address_of_new_memory, start_address_of_new_memory +
count_of_sections * memory_block_size] memory range
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/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
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
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
|
+-+-+-+
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
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
,
ZONE_HIGHMEM).
Updated the related Documentation.
Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
Documentation/ABI/testing/sysfs-devices-memory | 9 +
Documentation/memory-hotplug.txt | 4 +++-
drivers/base/memory.c | 15 ++-
3 files
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.
2. If the memory block
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
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
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/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
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
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
Hi,
Now we can hot-add memory by
% echo start_address_of_new_memory > /sys/devices/system/memory/probe
Then, [start_address_of_new_memory, start_address_of_new_memory +
memory_block_size] memory range is hot-added.
But we can only hot-add *one section one time* by this way.
Whether we can add
On 2014/6/12 6:08, David Rientjes wrote:
> On Wed, 11 Jun 2014, Zhang Zhen wrote:
>
>> Hi,
>>
>> Now we can hot-add memory by
>>
>> % echo start_address_of_new_memory > /sys/devices/system/memory/probe
>>
>> Then, [start_address_of_new_memory,
On 2014/6/12 15:07, David Rientjes wrote:
> On Thu, 12 Jun 2014, Zhang Zhen wrote:
>
>>>> % echo start_address_of_new_memory count_of_sections >
>>>> /sys/devices/system/memory/probe
>>>>
>>>> Then, [start_address_of_new_mem
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/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
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 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
1 - 100 of 110 matches
Mail list logo
