e
walk. Anyway 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 Hocko
SUSE Labs
--
Marcin Jabrzyk
Samsung R&D 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
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 i
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. Sorr
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(-)
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/Kc
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):
#
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/Kc
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 th
,
+ cpu);
+
+ continue;
+ }
+ pcpu_mevt->evt.irq = mct_irq;
+ irq_force_affinity(mct_irq, cpumask_of(cpu));
+
+ disable_irq(mct_irq);
+
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
o it's probably 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 n
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
be similar problem on qcom-timer I think just after looking
on the code.
Best regards,
--
Marcin Jabrzyk
Samsung R&D 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
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 and E
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 appli
20 matches
Mail list logo
