delay the write out to disc.
I like this idea and those benefits, the only question I'm not sure is
would it be too complicate to implement this feature? It sounds like we
need to reimplement something like swapcache to handle zswap write through.
--
Regards,
-Bob
--
To unsubscribe from this list
need so many changes to core VM/VFS subsystem because
it's based on cleancache API. I think it's more acceptable.
--
Regards,
--Bob
--
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
th Rik and he feel positive about zram.
>
> Last impression Andrw gave me by private mail is he want to merge
> zram's functionality into zswap or vise versa.
> If I misunderstood, please correct me.
> I understand his concern but I guess he didn't have a time to read
> my long descrip
p_frontswap_invalidate_page(type, offset);
I'm afraid when arrives here zswap_rb_search(offset) will always return
NULL entry. So most of the time, it's just waste time to call
zswap_frontswap_invalidate_page() to search rbtree.
--
Regards,
-Bob
--
To unsubscribe from this list: send the line "
zswap_frontswap_invalidate_page() to search rbtree.
--
Regards,
-Bob
--
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
Please read the FAQ at http://www.tux.org
that we can
move forward than stall.
Recently, Bob tried to move zsmalloc under mm directory to unify
zram and zswap with adding pseudo block device in zswap(It's
very weired to me. I think it's horrible monster which is lying
between mm and block in layering POV) but he was ignoring zram's
y, should the other places using max_pfn also be changed with
get_num_physpages()?
> balloon_stats.target_pages = balloon_stats.current_pages;
> balloon_stats.balloon_low = 0;
> balloon_stats.balloon_high = 0;
>
--
Regards,
-Bob
--
To unsubscribe
with
get_num_physpages()?
balloon_stats.target_pages = balloon_stats.current_pages;
balloon_stats.balloon_low = 0;
balloon_stats.balloon_high = 0;
--
Regards,
-Bob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On 11/05/2013 01:22 AM, David Vrabel wrote:
> On 04/11/13 12:39, Bob Liu wrote:
>> Currently the goal_page in xen-selfballon doesn't consider much about pages
>> used
>> in kernel space.
>> A typical usage is slab pages, without consider slab pages the goal_page
&g
Currently the goal_page in xen-selfballon doesn't consider much about pages used
in kernel space.
A typical usage is slab pages, without consider slab pages the goal_page result
may be too rough and lead extra memory pressure to guest os.
Signed-off-by: Bob Liu
---
drivers/xen/xen-selfballoon.c
On 11/05/2013 01:22 AM, David Vrabel wrote:
On 04/11/13 12:39, Bob Liu wrote:
Currently the goal_page in xen-selfballon doesn't consider much about pages
used
in kernel space.
A typical usage is slab pages, without consider slab pages the goal_page
result
may be too rough and lead extra
Currently the goal_page in xen-selfballon doesn't consider much about pages used
in kernel space.
A typical usage is slab pages, without consider slab pages the goal_page result
may be too rough and lead extra memory pressure to guest os.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/xen
t a sysfs node like
"/sys/block/zram0/clear_congested".
--
Regards,
-Bob
--
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
Please read the FAQ at http://www.tux.org/lkml/
,
-Bob
--
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
Please read the FAQ at http://www.tux.org/lkml/
Hi Olav,
On 11/01/2013 07:34 AM, Olav Haugan wrote:
> Hi Luigi,
>
> On 10/24/2013 6:12 PM, Luigi Semenzato wrote:
>> On Thu, Oct 24, 2013 at 5:35 PM, Olav Haugan wrote:
>>> Hi Bob, Luigi,
>>>
>>> On 10/23/2013 5:55 PM, Bob Liu wrote:
>>&
Hi Olav,
On 11/01/2013 07:34 AM, Olav Haugan wrote:
Hi Luigi,
On 10/24/2013 6:12 PM, Luigi Semenzato wrote:
On Thu, Oct 24, 2013 at 5:35 PM, Olav Haugan ohau...@codeaurora.org wrote:
Hi Bob, Luigi,
On 10/23/2013 5:55 PM, Bob Liu wrote:
On 10/24/2013 05:51 AM, Olav Haugan wrote
On Mon, Oct 21, 2013 at 06:40:41PM -0500, Bob Tracy wrote:
> On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
> > On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
> > > Actually, a regression: the 3.11 kernel is rock-solid stable
On Mon, Oct 21, 2013 at 06:40:41PM -0500, Bob Tracy wrote:
On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
Actually, a regression: the 3.11 kernel is rock-solid stable on my
Alpha.
Beginning
On 10/25/2013 08:35 AM, Olav Haugan wrote:
> Hi Bob, Luigi,
>
> On 10/23/2013 5:55 PM, Bob Liu wrote:
>>
>> On 10/24/2013 05:51 AM, Olav Haugan wrote:
>>> I am trying to use zram in very low memory conditions and I am having
>>> some issues. zram is in the
On 10/25/2013 08:35 AM, Olav Haugan wrote:
Hi Bob, Luigi,
On 10/23/2013 5:55 PM, Bob Liu wrote:
On 10/24/2013 05:51 AM, Olav Haugan wrote:
I am trying to use zram in very low memory conditions and I am having
some issues. zram is in the reclaim path. So if the system is very low
on memory
bj_idx starts
> at 0). zs_malloc returns the handle but does not distinguish between a
> valid handle of 0 and a failure to allocate. A possible solution to this
> would be to start the obj_idx at 1. Is this feasible?
>
> Thanks,
>
> Olav Haugan
>
--
Regards,
-Bob
--
to allocate. A possible solution to this
would be to start the obj_idx at 1. Is this feasible?
Thanks,
Olav Haugan
--
Regards,
-Bob
--
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
On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
> On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
> > Actually, a regression: the 3.11 kernel is rock-solid stable on my
> > Alpha.
> >
> > Beginning with 3.12.0-rc1, I can reli
had a
legitimate bug sighting.
I'll have to transcribe the panic backtrace by hand: nothing makes it
into any of the system logs :-(. I *can* recall that every backtrace
I've seen thus far has included one of the skb_copy() variants near the
top of the list (first or second function).
--Bob
--
To un
have to transcribe the panic backtrace by hand: nothing makes it
into any of the system logs :-(. I *can* recall that every backtrace
I've seen thus far has included one of the skb_copy() variants near the
top of the list (first or second function).
--Bob
--
To unsubscribe from this list: send
On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
Actually, a regression: the 3.11 kernel is rock-solid stable on my
Alpha.
Beginning with 3.12.0-rc1, I can reliably trigger a kernel panic by
executing
ion with a recent kernel. The FC19 distro
version may be fine, for all I know.
Arend says he used the latest version from the repo which should
not be a problem, but just throwing that out there since the
symptoms are similar.
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from
ice input
Perhaps this is an instance of this bug?
https://lkml.org/lkml/2013/5/31/426
tl;dr try with latest trace-cmd? I hit the above myself.
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
code to know
> what could be causing this, and we don't typically run with NUMA
> balancing on, so I don't see this in my everyday testing, but I felt
> that it was definitely worth bringing up.
>
> If anybody has any ideas of where I could poke around to find a
> solution,
don't see this in my everyday testing, but I felt
that it was definitely worth bringing up.
If anybody has any ideas of where I could poke around to find a
solution, please let me know.
--
Regards,
--Bob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
? I hit the above myself.
--
Bob Copeland %% www.bobcopeland.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
Please read the FAQ at http
distro
version may be fine, for all I know.
Arend says he used the latest version from the repo which should
not be a problem, but just throwing that out there since the
symptoms are similar.
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line unsubscribe linux
On Sat, Oct 12, 2013 at 5:14 PM, Weijie Yang wrote:
> On Sat, Oct 12, 2013 at 10:50 AM, Bob Liu wrote:
>> On Fri, Oct 11, 2013 at 3:13 PM, Minchan Kim wrote:
>>> On Thu, Sep 26, 2013 at 11:42:17AM +0800, Weijie Yang wrote:
>>>> On Tue, Sep 24, 2013 at 9:03 AM, Min
On Sat, Oct 12, 2013 at 5:14 PM, Weijie Yang weijie.yang...@gmail.com wrote:
On Sat, Oct 12, 2013 at 10:50 AM, Bob Liu lliu...@gmail.com wrote:
On Fri, Oct 11, 2013 at 3:13 PM, Minchan Kim minc...@kernel.org wrote:
On Thu, Sep 26, 2013 at 11:42:17AM +0800, Weijie Yang wrote:
On Tue, Sep 24
but I think it would be no problem because more bottleneck would be
>> > [de]compress
>> > functions. If it were really problem, we can mitigate a problem with moving
>> > unnecessary functions out of zswap_free_entry because it seem to be rather
>> > over-eng
p_free_entry because it seem to be rather
>> over-enginnering.
>
> I refactor the zswap refcount routine according to Minchan's idea.
> Here is the new patch, Any suggestion is welcomed.
>
> To Seth and Bob, would you please review it again?
>
I have nothing in addition to Min
, we can mitigate a problem with moving
unnecessary functions out of zswap_free_entry because it seem to be rather
over-enginnering.
I refactor the zswap refcount routine according to Minchan's idea.
Here is the new patch, Any suggestion is welcomed.
To Seth and Bob, would you please review
is the new patch, Any suggestion is welcomed.
To Seth and Bob, would you please review it again?
Yeah, Seth, Bob. You guys are right persons to review this because this
scheme was suggested by me who is biased so it couldn't be a fair. ;-)
But anyway, I will review code itself.
mm/zswap.c
s this?
>>>>
>>>> Are there any runtime-visible effects from this change?
>>>
>>> I tested zswap on x86 and x86-64 and there was no difference. This is
>>> good as there shouldn't be visible anything because swapoff is unusing
>>> al
nd there was no difference. This is
>> good as there shouldn't be visible anything because swapoff is unusing
>> all pages anyway:
>> try_to_unuse(type, false, 0); /* force all pages to be unused */
>>
>> I haven't tested other frontswap users.
>
> So is that code in __frontswap_inv
needed otherwise there will be memory leak.
I'm afraid nobody noticed the memory leak here before, this patch can
fix it. Sorry for didn't pay enough attention but please keep
__frontswap_invalidate_area().
--
Regards,
-Bob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
in __frontswap_invalidate_area() unneeded?
Yes, to expand on what Bob said, __frontswap_invalidate_area() is still
needed to let any frontswap backend free per-swaptype resources.
__frontswap_invalidate_area() is _not_ for freeing structures associated
with individual swapped out pages since all of the pages
Nobody uses the pvec->cold argument of pagevec and it's also unreasonable for
pages in pagevec released as cold page, so drop the cold argument from pagevec.
Signed-off-by: Bob Liu
---
fs/9p/cache.c |2 +-
fs/afs/cache.c |2 +-
fs/afs/write.c |4 ++--
Nobody uses the pvec-cold argument of pagevec and it's also unreasonable for
pages in pagevec released as cold page, so drop the cold argument from pagevec.
Signed-off-by: Bob Liu bob@oracle.com
---
fs/9p/cache.c |2 +-
fs/afs/cache.c |2 +-
fs/afs/write.c
However, as I have discovered today, this is problematic when it comes
> to reclaim and migration and serializing access.
>
> I wanted to do as much as possible in the zswap layer since anything
> done in the zbud layer would need to be duplicated in any other future
> allocator tha
.
zswap_entry can be still in rbtree or maybe changed to radix tree.
There is a sample code in my previous email.
--
Regards,
-Bob
--
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
;
>>> > On Wed, Sep 25, 2013 at 05:33:43PM +0800, Weijie Yang wrote:
>>> >> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
>>> >> > On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang
>>> >> > wrote:
>>> >> >> I think
t week
> ago. I assumed you would test it, but I probably should make that
> request explicit, sorry. Anyway it was added to -mm an hour before your
> mail.
>
Great! And please ignore my noise in this thread.
--
Regards,
--Bob
--
To unsubscribe from this list: send the line "
test it, but I probably should make that
request explicit, sorry. Anyway it was added to -mm an hour before your
mail.
Great! And please ignore my noise in this thread.
--
Regards,
--Bob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
,
On Wed, Sep 25, 2013 at 05:33:43PM +0800, Weijie Yang wrote:
On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu lliu...@gmail.com wrote:
On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang
weijie.yang...@gmail.com wrote:
I think I find a new issue, for integrity of this mail thread, I reply
On Thu, Sep 26, 2013 at 9:59 AM, Fengguang Wu wrote:
> Hi Bob,
>
> On Thu, Sep 26, 2013 at 09:48:08AM +0800, Bob Liu wrote:
>> Hi Fengguang,
>>
>> Would you please have a try with the attached patch?
>> It added a small fix based on Vlastimil's patch.
>
>
Hi Fengguang,
Would you please have a try with the attached patch?
It added a small fix based on Vlastimil's patch.
Thanks,
-Bob
On 09/26/2013 08:40 AM, Fengguang Wu wrote:
> Hi Vlastimil,
>
> FYI, this bug seems still not fixed in linux-next 20130925.
&g
On Wed, Sep 25, 2013 at 5:33 PM, Weijie Yang wrote:
> On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu wrote:
>> On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang
>> wrote:
>>> I think I find a new issue, for integrity of this mail thread, I reply
>>> to this mail.
>>
t; error will happen If do_swap_page() get page from swap_cache.
>
--
Regards,
--Bob
--
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
Please read the FAQ at http://www.tux.org/lkml/
.
--
Regards,
--Bob
--
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
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Sep 25, 2013 at 5:33 PM, Weijie Yang weijie.yang...@gmail.com wrote:
On Wed, Sep 25, 2013 at 4:31 PM, Bob Liu lliu...@gmail.com wrote:
On Wed, Sep 25, 2013 at 4:09 PM, Weijie Yang weijie.yang...@gmail.com
wrote:
I think I find a new issue, for integrity of this mail thread, I reply
Hi Fengguang,
Would you please have a try with the attached patch?
It added a small fix based on Vlastimil's patch.
Thanks,
-Bob
On 09/26/2013 08:40 AM, Fengguang Wu wrote:
Hi Vlastimil,
FYI, this bug seems still not fixed in linux-next 20130925.
commit
On Thu, Sep 26, 2013 at 9:59 AM, Fengguang Wu fengguang...@intel.com wrote:
Hi Bob,
On Thu, Sep 26, 2013 at 09:48:08AM +0800, Bob Liu wrote:
Hi Fengguang,
Would you please have a try with the attached patch?
It added a small fix based on Vlastimil's patch.
Thanks for the quick response! I
On Tue, Sep 24, 2013 at 5:20 PM, Krzysztof Kozlowski
wrote:
> Hi,
>
> On pon, 2013-09-23 at 17:07 -0500, Seth Jennings wrote:
>> On Tue, Sep 17, 2013 at 02:59:24PM +0800, Bob Liu wrote:
>> > Mel mentioned several problems about zswap/zbud in thread "[PATCH v6
>
On Tue, Sep 24, 2013 at 5:20 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Hi,
On pon, 2013-09-23 at 17:07 -0500, Seth Jennings wrote:
On Tue, Sep 17, 2013 at 02:59:24PM +0800, Bob Liu wrote:
Mel mentioned several problems about zswap/zbud in thread [PATCH v6
0/5] zram/zsmalloc
iously. It's likely that it was PageWriteback you wanted in zbud.c too.
--
Regards,
-Bob
--
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
Please read the FAQ at http://www.tux.org/lkml/
wanted in zbud.c too.
--
Regards,
-Bob
--
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
Please read the FAQ at http://www.tux.org
MD_SIZE) & PMD_MASK;
+ end = (pmd_end - 1 < end - 1) ? pmd_end : end;
/*
* Initialize pte walk starting at the already pinned page where we
* are sure that there is a pte.
*/
pte = get_locked_pte(vma->vm_mm, start, );
- end =
and written back with an address space ops and
properly handled asynchonous writeback."
So I think it would be better if we can address those issues at first
and it would be easier to address these issues before adding more new
features. Welcome any ideas.
--
Regards,
-Bob
--
To unsubscribe from th
asynchonous writeback.
So I think it would be better if we can address those issues at first
and it would be easier to address these issues before adding more new
features. Welcome any ideas.
--
Regards,
-Bob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
to the pinned page is the first we will try to
get */
start += PAGE_SIZE;
Anyway,
Reviewed-by: Bob Liu bob@oracle.com
--
Regards,
-Bob
--
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
with this topic, I don't know whether this
series can also fix the issue I mentioned.
--
Regards,
-Bob
--
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.
fix the issue I mentioned.
--
Regards,
-Bob
--
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
Please read the FAQ at http://www.tux.org/lkml/
; additional reclaim paths.
>
> The page count is incremented when:
> - a handle is created and passed to zswap (in zbud_alloc()),
> - user-supplied eviction callback is called (in zbud_reclaim_page()).
>
> Signed-off-by: Krzysztof Kozlowski
> Signed-off-by: Tomasz Sta
...@samsung.com
Reviewed-by: Bob Liu bob@oracle.com
AFAIR, the previous version you sent out has a function called
rebalance_lists() which I think is a good clean up.
But I didn't see that function any more in this version.
Thanks,
-Bob
---
mm/zbud.c | 97
>
> /* allocate entry */
> - entry = zswap_entry_cache_alloc(GFP_KERNEL);
> + entry = zswap_entry_cache_alloc(GFP_NOIO);
> if (!entry) {
> zswap_reject_kmemcache_fail++;
> ret = -ENOMEM;
>
--
Regards,
-Bob
--
To unsubscribe from this list:
t also by invalidate.
>
> Signed-off-by: Weijie Yang
Reviewed-by: Bob Liu
> ---
> mm/zswap.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index cbd9578..1be7b90 100644
> --- a/mm/zswap.c
&
On 09/06/2013 01:16 PM, Weijie Yang wrote:
> add SetPageReclaim before __swap_writepage so that page can be moved to the
> tail of the inactive list, which can avoid unnecessary page scanning as this
> page was reclaimed by swap subsystem before.
>
> Signed-off-by: Weijie Yang
R
On 09/06/2013 01:16 PM, Weijie Yang wrote:
> zswap_tree is not freed when swapoff, and it got re-kmalloc in swapon,
> so memory-leak occurs.
>
> Modify: free memory of zswap_tree in zswap_frontswap_invalidate_area().
>
> Signed-off-by: Weijie Yang
Reviewed-by: Bob Liu
&
On 09/06/2013 01:16 PM, Weijie Yang wrote:
zswap_tree is not freed when swapoff, and it got re-kmalloc in swapon,
so memory-leak occurs.
Modify: free memory of zswap_tree in zswap_frontswap_invalidate_area().
Signed-off-by: Weijie Yang weijie.y...@samsung.com
Reviewed-by: Bob Liu bob
Reviewed-by: Bob Liu bob@oracle.com
---
mm/zswap.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/zswap.c b/mm/zswap.c
index 1be7b90..cc40e6a 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -556,6 +556,9 @@ static int zswap_writeback_entry(struct zbud_pool *pool
...@samsung.com
Reviewed-by: Bob Liu bob@oracle.com
---
mm/zswap.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index cbd9578..1be7b90 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -387,7 +387,7 @@ static void
(GFP_NOIO);
if (!entry) {
zswap_reject_kmemcache_fail++;
ret = -ENOMEM;
--
Regards,
-Bob
--
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, Aug 30, 2013 at 2:14 PM, Dan Aloni wrote:
> On Fri, Aug 30, 2013 at 01:47:53PM +0800, Bob Liu wrote:
>>[..]
>> Machine2: bootcmdline in grub.cfg "memmap=0x77ff$0x88000", the
>> result of
>> "cat /proc/cmdline" changed to "memmap
On Fri, Aug 30, 2013 at 2:14 PM, Dan Aloni alo...@stratoscale.com wrote:
On Fri, Aug 30, 2013 at 01:47:53PM +0800, Bob Liu wrote:
[..]
Machine2: bootcmdline in grub.cfg memmap=0x77ff$0x88000, the
result of
cat /proc/cmdline changed to memmap=0x77ffx88000.
I didn't find
didn't find the root cause, I think maybe grub reserved "$0" as something
special.
Replace '$' with '%' in kernel boot parameter can fix this issue.
Signed-off-by: Bob Liu
---
Documentation/kernel-parameters.txt |6 +++---
arch/x86/kernel/e820.c |2 +-
2 files chang
special.
Replace '$' with '%' in kernel boot parameter can fix this issue.
Signed-off-by: Bob Liu bob@oracle.com
---
Documentation/kernel-parameters.txt |6 +++---
arch/x86/kernel/e820.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation
Hi Minchan,
On Thu, Aug 22, 2013 at 8:42 AM, Minchan Kim wrote:
> Hi Bob,
>
> On Wed, Aug 21, 2013 at 05:24:00PM +0800, Bob Liu wrote:
>> Hi Minchan,
>>
>> On 08/21/2013 02:16 PM, Minchan Kim wrote:
>> > It's 7th trial of zram/zsmalloc promotion.
>&
Hi Minchan,
On Thu, Aug 22, 2013 at 8:42 AM, Minchan Kim minc...@kernel.org wrote:
Hi Bob,
On Wed, Aug 21, 2013 at 05:24:00PM +0800, Bob Liu wrote:
Hi Minchan,
On 08/21/2013 02:16 PM, Minchan Kim wrote:
It's 7th trial of zram/zsmalloc promotion.
I rewrote cover-letter totally based
On 08/21/2013 05:24 PM, Bob Liu wrote:
> Hi Minchan,
>
> On 08/21/2013 02:16 PM, Minchan Kim wrote:
>> It's 7th trial of zram/zsmalloc promotion.
>> I rewrote cover-letter totally based on previous discussion.
>>
>> The main reason to prevent zram promotion was no
edictable behavior because we can expect a zpage
> includes just two pages as maximum. Other reviews were not major.
> http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04334.html
>
> Zcache doesn't use zsmalloc either so zsmalloc's user is only
> zram now so this patchset moves it
as maximum. Other reviews were not major.
http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04334.html
Zcache doesn't use zsmalloc either so zsmalloc's user is only
zram now so this patchset moves it into zsmalloc directory.
Recently, Bob tried to move zsmalloc under mm directory
On 08/21/2013 05:24 PM, Bob Liu wrote:
Hi Minchan,
On 08/21/2013 02:16 PM, Minchan Kim wrote:
It's 7th trial of zram/zsmalloc promotion.
I rewrote cover-letter totally based on previous discussion.
The main reason to prevent zram promotion was no review of
zsmalloc part while Jens, block
On 08/20/2013 01:46 AM, Seth Jennings wrote:
> On Sun, Aug 18, 2013 at 04:40:49PM +0800, Bob Liu wrote:
>> This is used to replace previous zram.
>> zram users can enable this feature, then a pseudo device will be created
>> automaticlly after kernel boot.
>> Just usin
On 08/20/2013 12:59 AM, Seth Jennings wrote:
> On Sun, Aug 18, 2013 at 04:40:48PM +0800, Bob Liu wrote:
>> Make zswap can use zsmalloc as its allocater.
>> But note that zsmalloc don't reclaim any zswap pool pages mandatory, if zswap
>> pool gets full, frontswap_store w
d is not so unusual that we are the only Linux
> users in this situation, and that zsmalloc (or other
> allocator-compressor with similar characteristics) will continue to
> exist, whether it is used by zram or zswap.
>
> Thanks!
>
--
Regards,
-Bob
--
To unsubscribe f
(or other
allocator-compressor with similar characteristics) will continue to
exist, whether it is used by zram or zswap.
Thanks!
--
Regards,
-Bob
--
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
On 08/20/2013 12:59 AM, Seth Jennings wrote:
On Sun, Aug 18, 2013 at 04:40:48PM +0800, Bob Liu wrote:
Make zswap can use zsmalloc as its allocater.
But note that zsmalloc don't reclaim any zswap pool pages mandatory, if zswap
pool gets full, frontswap_store will be refused unless
On 08/20/2013 01:46 AM, Seth Jennings wrote:
On Sun, Aug 18, 2013 at 04:40:49PM +0800, Bob Liu wrote:
This is used to replace previous zram.
zram users can enable this feature, then a pseudo device will be created
automaticlly after kernel boot.
Just using mkswp /dev/zram0; swapon /dev/zram0
Hi Minchan,
On 08/19/2013 12:10 PM, Minchan Kim wrote:
> On Sun, Aug 18, 2013 at 04:40:45PM +0800, Bob Liu wrote:
>> Both zswap and zram are used to compress anon pages in memory so as to reduce
>> swap io operation. The main different is that zswap uses zbud as its
>> al
in zram
> 3) implement writebazk in zram
>
> The zram has been for a long time in staging to be promoted and have been
> maintained/deployed. Of course, I have asked the promotion several times
> for above a year.
>
> Why can't zram include zswap functions if you really want to merge them?
> Is there any problem?
I think merging zram into zswap or merging zswap into zram are the same
thing. It's no difference.
Both way will result in a solution finally with zram block device,
frontswap API etc.
The difference is just the name and the merging patch title, I think
it's unimportant.
I've implemented a series [PATCH 0/4] mm: merge zram into zswap, I can
change the tile to "merge zswap into zram" if you want and rename zswap
to something like zhybrid.
--
Regards,
-Bob
--
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
Please read the FAQ at http://www.tux.org/lkml/
aim
> function, does this lead to these function called recursively?
Yes, that's a potential problem.
> 3. for reclaiming one zbud page which contains two buddies, zswap
> needs to alloc two pages. Does this reclaim cost-efficient?
>
Yes, that's a problem too. And that's why we use zbud
parameter
zswap.max_pool_percent.
disksize = (totalram_pages * zswap.max_pool_percent/100)*PAGE_SIZE.
Signed-off-by: Bob Liu
---
mm/Kconfig | 12
mm/zswap.c | 196
2 files changed, 208 insertions(+)
diff --git a/mm/Kconfig b/mm/Kconfig
ind
, zsmalloc has unpredictable performance characteristics when
reclaiming a single page, then CONFIG_ZBUD are suggested.
Signed-off-by: Bob Liu
---
include/linux/zsmalloc.h |1 +
mm/Kconfig |4 +++
mm/zsmalloc.c|9 --
mm/zswap.c | 73
sponse to an allocation request.
That handle must be mapped, using zs_map_object(), which returns
a pointer to the mapped region that can be used. The mapping is
necessary since the object data may reside in two different
noncontigious pages.
Signed-off-by: Bob Liu
---
include/linux/zsmalloc.
901 - 1000 of 1668 matches
Mail list logo
