y even these counters might get quite tricky because even
shareable resources are considered private if the process is the only
one to map them (so again this might be a file on tmpfs...).
Swap and
PSS also give us some indication of additional memory which might get
freed up.
--
Michal Hock
ivate if the process is the only
one to map them (so again this might be a file on tmpfs...).
Swap and
PSS also give us some indication of additional memory which might get
freed up.
--
Michal Hocko
SUSE Labs
--
Marcin Jabrzyk
Samsung R Institute Poland
Samsung Electronics
On 25/05/15 09:34, Sergey Senozhatsky wrote:
On (05/25/15 09:15), Marcin Jabrzyk wrote:
[..]
I'm perfectly fine with this solution. It just does what
I'd expect.
cool, let's hear from Minchan.
btw, if we decide to move on, how do you guys want to route
it? do you want Marcin (I don't
Hi Sergey,
On 25/05/15 08:18, Sergey Senozhatsky wrote:
On (05/22/15 15:26), Marcin Jabrzyk wrote:
From the other hand, the only valid values that can be written are
in 'comp_algorithm'.
So when writing other one, returning -EINVAL seems to be reasonable.
The user would get immediately
On 25/05/15 09:34, Sergey Senozhatsky wrote:
On (05/25/15 09:15), Marcin Jabrzyk wrote:
[..]
I'm perfectly fine with this solution. It just does what
I'd expect.
cool, let's hear from Minchan.
btw, if we decide to move on, how do you guys want to route
it? do you want Marcin (I don't
Hi Sergey,
On 25/05/15 08:18, Sergey Senozhatsky wrote:
On (05/22/15 15:26), Marcin Jabrzyk wrote:
From the other hand, the only valid values that can be written are
in 'comp_algorithm'.
So when writing other one, returning -EINVAL seems to be reasonable.
The user would get immediately
Hello Minchan,
On 22/05/15 15:14, Minchan Kim wrote:
Hello Sergey,
On Fri, May 22, 2015 at 09:44:11PM +0900, Sergey Senozhatsky wrote:
On (05/22/15 11:12), Marcin Jabrzyk wrote:
no.
zram already complains about failed comp backend creation.
it's in dmesg (or syslog, etc.):
"
On 22/05/15 14:44, Sergey Senozhatsky wrote:
On (05/22/15 11:12), Marcin Jabrzyk wrote:
no.
zram already complains about failed comp backend creation.
it's in dmesg (or syslog, etc.):
"zram: Cannot initialise %s compressing backend"
OK, now I see that. Sorry for
Hi,
On 22/05/15 10:56, Sergey Senozhatsky wrote:
On (05/22/15 10:31), Marcin Jabrzyk wrote:
Zram sysfs interface was not making any check of
proper compressor name when setting it.
Any name is accepted, but further tries of device
creation would end up with not very meaningfull error.
eg
commit fixes that behaviour with returning
EINVAL and proper error message.
Signed-off-by: Marcin Jabrzyk
---
drivers/block/zram/zcomp.c| 22 +++---
drivers/block/zram/zcomp.h| 1 +
drivers/block/zram/zram_drv.c | 5 +
3 files changed, 17 insertions(+), 11 deletions(-)
that behaviour with returning
EINVAL and proper error message.
Signed-off-by: Marcin Jabrzyk m.jabr...@samsung.com
---
drivers/block/zram/zcomp.c| 22 +++---
drivers/block/zram/zcomp.h| 1 +
drivers/block/zram/zram_drv.c | 5 +
3 files changed, 17 insertions(+), 11
Hi,
On 22/05/15 10:56, Sergey Senozhatsky wrote:
On (05/22/15 10:31), Marcin Jabrzyk wrote:
Zram sysfs interface was not making any check of
proper compressor name when setting it.
Any name is accepted, but further tries of device
creation would end up with not very meaningfull error.
eg
On 22/05/15 14:44, Sergey Senozhatsky wrote:
On (05/22/15 11:12), Marcin Jabrzyk wrote:
no.
zram already complains about failed comp backend creation.
it's in dmesg (or syslog, etc.):
zram: Cannot initialise %s compressing backend
OK, now I see that. Sorry for the noise.
second
Hello Minchan,
On 22/05/15 15:14, Minchan Kim wrote:
Hello Sergey,
On Fri, May 22, 2015 at 09:44:11PM +0900, Sergey Senozhatsky wrote:
On (05/22/15 11:12), Marcin Jabrzyk wrote:
no.
zram already complains about failed comp backend creation.
it's in dmesg (or syslog, etc.):
zram
The DEBUG define in zsmalloc is useless, there
is no usage of it at all.
Signed-off-by: Marcin Jabrzyk
---
mm/zsmalloc.c | 4
1 file changed, 4 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 08bd7a3d464a..33d512646379 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -45,10
This config option doesn't provide any usage for zram.
Signed-off-by: Marcin Jabrzyk
---
drivers/block/zram/Kconfig| 10 +-
drivers/block/zram/zram_drv.c | 4
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
This patchset removes unused DEBUG defines in zram and zsmalloc,
that remained in sources and config without actual usage.
Changes from v1:
- Apply the removal also to zsmalloc
Marcin Jabrzyk (2):
zram: remove obsolete ZRAM_DEBUG option
zsmalloc: remove obsolete ZSMALLOC_DEBUG
drivers
On 22/04/15 01:55, Sergey Senozhatsky wrote:
On (04/21/15 13:20), Marcin Jabrzyk wrote:
This config option doesn't provide any usage for zram.
agree, there is no pr_debug() in the current zram. so the change
looks good to me.
btw, same stands for zsmalloc (for the time being):
#ifdef
On 22/04/15 01:55, Sergey Senozhatsky wrote:
On (04/21/15 13:20), Marcin Jabrzyk wrote:
This config option doesn't provide any usage for zram.
agree, there is no pr_debug() in the current zram. so the change
looks good to me.
btw, same stands for zsmalloc (for the time being):
#ifdef
This patchset removes unused DEBUG defines in zram and zsmalloc,
that remained in sources and config without actual usage.
Changes from v1:
- Apply the removal also to zsmalloc
Marcin Jabrzyk (2):
zram: remove obsolete ZRAM_DEBUG option
zsmalloc: remove obsolete ZSMALLOC_DEBUG
drivers
This config option doesn't provide any usage for zram.
Signed-off-by: Marcin Jabrzyk m.jabr...@samsung.com
---
drivers/block/zram/Kconfig| 10 +-
drivers/block/zram/zram_drv.c | 4
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/block/zram/Kconfig b
The DEBUG define in zsmalloc is useless, there
is no usage of it at all.
Signed-off-by: Marcin Jabrzyk m.jabr...@samsung.com
---
mm/zsmalloc.c | 4
1 file changed, 4 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 08bd7a3d464a..33d512646379 100644
--- a/mm/zsmalloc.c
+++ b/mm
This config option doesn't provide any usage for zram.
Signed-off-by: Marcin Jabrzyk
---
drivers/block/zram/Kconfig| 10 +-
drivers/block/zram/zram_drv.c | 4
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
This config option doesn't provide any usage for zram.
Signed-off-by: Marcin Jabrzyk m.jabr...@samsung.com
---
drivers/block/zram/Kconfig| 10 +-
drivers/block/zram/zram_drv.c | 4
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/block/zram/Kconfig b
On 31/01/15 10:21, Daniel Lezcano wrote:
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG
cpu);
+
+ continue;
+ }
+ pcpu_mevt->evt.irq = mct_irq;
+ irq_force_affinity(mct_irq, cpumask_of(cpu));
+
+ disable_irq(mct_irq);
+ }
}
err = register_cp
));
+
+ disable_irq(mct_irq);
+ }
}
err = register_cpu_notifier(exynos4_mct_cpu_nb);
Tested-by: Marcin Jabrzyk m.jabr...@samsung.com
Test hardware: Rinato B2 (Exynos 3250) board
I can confirm that this fixes bug reported here [1] BUG appearing
On 31/01/15 10:21, Daniel Lezcano wrote:
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG
Minor fixes for cleancache about wrong debugfs paths
in documentation and code comment.
Signed-off-by: Marcin Jabrzyk
---
Documentation/vm/cleancache.txt | 2 +-
mm/cleancache.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/vm
Minor fixes for cleancache about wrong debugfs paths
in documentation and code comment.
Signed-off-by: Marcin Jabrzyk m.jabr...@samsung.com
---
Documentation/vm/cleancache.txt | 2 +-
mm/cleancache.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
not being attached to CPU1.
Best regards,
Marcin Jabrzyk
On 27/10/14 21:16, Stephen Boyd wrote:
On 10/24/2014 06:22 AM, Marcin Jabrzyk wrote:
On 23/10/14 20:41, Stephen Boyd wrote:
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
The CPU notifier is called via notify_cpu_startin
attached to CPU1.
Best regards,
Marcin Jabrzyk
On 27/10/14 21:16, Stephen Boyd wrote:
On 10/24/2014 06:22 AM, Marcin Jabrzyk wrote:
On 23/10/14 20:41, Stephen Boyd wrote:
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
The CPU notifier is called via notify_cpu_starting(), which is called
On 23/10/14 20:41, Stephen Boyd wrote:
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
[1.] One line summary of the problem: "BUG: sleeping function called from
invalid context at mm/slub.c:1250" after CPU ho
On 23/10/14 20:41, Stephen Boyd wrote:
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
[1.] One line summary of the problem: BUG: sleeping function called from
invalid context at mm/slub.c:1250 after CPU hotplug
I'm
imilar problem on qcom-timer I think just after looking
on the code.
Best regards,
--
Marcin Jabrzyk
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
for started CPU and then BUG appears.
There might be similar problem on qcom-timer I think just after looking
on the code.
Best regards,
--
Marcin Jabrzyk
Samsung RD Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hello,
W dniu 25.08.2014 o 16:02, Mathieu Poirier pisze:
> On 24 August 2014 15:38, Marcin Jabrzyk wrote:
>> Hi,
>>
>> W dniu 20.08.2014 o 19:03, mathieu.poir...@linaro.org pisze:
>>> From: Mathieu Poirier
>>>
>>> Currently supporting ETM
Hello,
W dniu 25.08.2014 o 16:02, Mathieu Poirier pisze:
On 24 August 2014 15:38, Marcin Jabrzyk marcin.jabr...@gmail.com wrote:
Hi,
W dniu 20.08.2014 o 19:03, mathieu.poir...@linaro.org pisze:
From: Mathieu Poirier mathieu.poir...@linaro.org
Currently supporting ETM and ETB. Support
Hi,
W dniu 20.08.2014 o 19:03, mathieu.poir...@linaro.org pisze:
> From: Mathieu Poirier
>
> Currently supporting ETM and ETB. Support for TPIU
> and SDTI are yet to be added.
Did you tried running the drivers on board or are there any special
preparation needed?
I've BeagleBoard-xM Rev. C
Hi,
W dniu 20.08.2014 o 19:03, mathieu.poir...@linaro.org pisze:
From: Mathieu Poirier mathieu.poir...@linaro.org
Currently supporting ETM and ETB. Support for TPIU
and SDTI are yet to be added.
Did you tried running the drivers on board or are there any special
preparation needed?
I've
40 matches
Mail list logo
