t yes there will be complicated and i think it's hard to eliminate the
effect to people who don't need any compression.
I'm not saying I have the solution. The ideal sizing of the compressed
pool is a complex issue and, like so many other elements of compressed
memory design
long time.
would anyone please to give me a hint to solve the problem.
thanks a lot.
Bob wang
--
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.h
Hi I have a dual PIII Motherboard based on a ServerWorks LE chipset,
the motherboard is from an HP Netserver E 800 which is a customised
ASUS CUR-DLS.
in UP config everything is OK in SMP the system slows right down,
I've been searching and recompiling my kernel for days looking for
the probl
Alan wrote:
As a test of raw CPU power I've been decompressing the kernel tree, with
a UP 2.6 kernel this takes about 1m 15s, I don't know if bz2 is
multithreaded but even if it's not I would expect a slight speed increase
but in fact with a SMP 2.6 kernel it take 13 ~ 26m, with a SMP 2.4
kern
Arjan van de Ven wrote:
in UP config everything is OK in SMP the system slows right down,
I've been searching and recompiling my kernel for days looking for
the problem option without success, please help.
does the linux-ready firmware kit work on this machine? (see url in
sig), it might be so
Bob wrote:
Hi I have a dual PIII Motherboard based on a ServerWorks LE chipset,
the motherboard is from an HP Netserver E 800 which is a customised ASUS
CUR-DLS.
in UP config everything is OK in SMP the system slows right down, I've
been searching and recompiling my kernel for days lo
Jeff V. Merkey wrote:
Alan wrote:
As per Alan's suggestion I decompressed the kernel source tree with
the processes pegged to one CPU then the other, and as he predicted
it took vastly longer on one CPU than the other, but I don't know
what that implies, or how to fix it.
From the timing it
hread+0x4a/0x3b0
[39019.426697] ? process_one_work+0x370/0x370
[39019.426699] kthread+0xfe/0x140
[39019.426701] ? kthread_park+0x90/0x90
[39019.426704] ret_from_fork+0x22/0x30
[39019.426706] ---[ end trace d512d675211c738c ]---
[39021.426751] [ cut here ]
Thanks in advance,
Bob
4: 7ffdfc946600 R15:
7ffdfc9482df
...and the oops repeats
I'm running kernel Linux freedom 5.2.0-rc6 #1 SMP Sun Jun 23 18:31:56
MDT 2019 x86_64 x86_64 x86_64 GNU/Linux
If you need more info, please reply to me directly as I'm not on the list,
Thanks,
Bob
Hello. I'm posting here because someone asked (a long time ago) for a
driver or app that would drive a little usb gadget (mini vga display)
called the screenDUO that comes with Asus motherboards. I recently put
a bunch of work into it (multiline support, color text, pixel drawing,
etc.) And i
possible deal.
b.rgds
Bob Hu
Ningbo Yinzhou Xusheng Machinery Factory
Cell: 0086-1395832 7774
Skype: bobhu1
Tel: 0086-574-88128603
b...@xs-aluminumcasting.com
www.xs-aluminumcasting.com
disp: 0c10: cf00
---
If you need anything else, please email me directly as I'm not on the list.
Bob
s I am not on the list,
Bob
Hi. I've been building kernels weekly since 1996. Never had one not
build before today. v5.9-rc6 does not compile.
Error:
AR drivers/gpu/built-in.a
make: *** [Makefile:1784: drivers] Error 2
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
DESCEND objtoo
#x27;m fairly certain the
NAS machine is using the ext4 filesystem and I don't think its a
filesystem size limit.
Thanks in advance, please email me directly as I am not on the list,
Bob
> ++++++-
> 6 files changed, 263 insertions(+), 8 deletions(-)
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
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 Tue, Nov 27, 2012 at 4:29 PM, Tang Chen wrote:
> On 11/27/2012 04:00 PM, Bob Liu wrote:
>>
>> Hi Tang,
>>
>> On Fri, Nov 23, 2012 at 6:44 PM, Tang Chen
>> wrote:
>>>
>>> [What we are doing]
>>> This patchset provide a boot option
On Tue, Nov 27, 2012 at 8:49 PM, Tang Chen wrote:
> On 11/27/2012 08:09 PM, Bob Liu wrote:
>>
>> On Tue, Nov 27, 2012 at 4:29 PM, Tang Chen
>> wrote:
>>>
>>> Hi Liu,
>>>
>>>
>>> This feature is used in memory hotplug.
>>&g
LT_FALLBACK);
if (is_huge_zero_pmd(orig_pmd)) {
ret = do_huge_pmd_wp_zero_page_fallback(mm, vma,
- address, pmd, haddr);
+ address, pmd, orig_pmd, haddr);
} else {
_free(void *pampd, struct
> tmem_pool *pool,
> }
> if (!is_local_client(pool->client))
> ramster_count_foreign_pages(is_ephemeral(pool), -1);
> - if (page)
> + if (page && !zero_filled)
> zcache_free_page(page);
> }
>
>
--
Rega
Stefan Hengelein
>> Signed-off-by: Florian Schmaus
>> Signed-off-by: Andor Daam
>> Signed-off-by: Dan Magenheimer
>> [v1: Fixes per Seth Jennings suggestions]
>> [v2: Removed FRONTSWAP_HAS_.. ]
>> [v3: Fix up per Bob
gtable(struct device *dev, struct sg_table *sgt,
> + void *cpu_addr, dma_addr_t dma_addr,
> + size_t size);
> +
> +#define dma_mmap_coherent(d, v, c, h, s) dma_common_mmap(d, v, c, h, s)
> +#define dma_get_sgtable(d, t, v, h, s) dma_common_ge
ic() APIs to prevent CPUs from going offline,
> while invoking from atomic context.
>
> Cc: Mike Frysinger
> Cc: Bob Liu
> Cc: Steven Miao
> Cc: uclinux-dist-de...@blackfin.uclinux.org
> Signed-off-by: Srivatsa S. Bhat
Thanks, will be applied to my blackfin arch tree.
&
- Original Message -
| 3.7-stable review patch. If anyone has any objections, please let me
| know.
|
| --
|
| From: Bob Peterson
|
| commit d2b47cfb26fe06002b8011707baac71a9ae8166f upstream.
|
| This patch allocates a block reservation structure before growing
| or
f656c240ae07c48ddf8552e83b64692121044c42:
blackfin: time-ts: Remove duplicate assignment (2013-02-20 15:21:23 +0800)
Akinobu Mita (1):
blackfin: use bitmap library functions
Bob Liu (1):
blackfin: mem_init: update dmc config register
ge_mapping(first_page, &class_idx, &fullness);
> + class = &pool->size_class[class_idx];
> + f_offset = obj_idx_to_offset(f_page, f_objidx, class->size);
> +
> + spin_lock(&class->lock);
> +
> + /* Insert this object in containing zspage's freelist */
> + link = (struct link_free *)((unsigned char *)kmap_atomic(f_page)
> + + f_offset);
> + link->next = first_page->freelist;
> + kunmap_atomic(link);
> + first_page->freelist = (void *)obj;
> +
> + first_page->inuse--;
> + fullness = fix_fullness_group(pool, first_page);
> +
> + if (fullness == ZS_EMPTY)
> + class->pages_allocated -= class->pages_per_zspage;
> +
> + spin_unlock(&class->lock);
> +
> + if (fullness == ZS_EMPTY)
> + free_zspage(pool->ops, first_page);
> +}
> +EXPORT_SYMBOL_GPL(zs_free);
> +
> +/**
> + * zs_map_object - get address of allocated object from handle.
> + * @pool: pool from which the object was allocated
> + * @handle: handle returned from zs_malloc
> + *
> + * Before using an object allocated from zs_malloc, it must be mapped using
> + * this function. When done with the object, it must be unmapped using
> + * zs_unmap_object.
> + *
> + * Only one object can be mapped per cpu at a time. There is no protection
> + * against nested mappings.
> + *
> + * This function returns with preemption and page faults disabled.
> +*/
> +void *zs_map_object(struct zs_pool *pool, unsigned long handle,
> + enum zs_mapmode mm)
> +{
> + struct page *page;
> + unsigned long obj_idx, off;
> +
> + unsigned int class_idx;
> + enum fullness_group fg;
> + struct size_class *class;
> + struct mapping_area *area;
> + struct page *pages[2];
> +
> + BUG_ON(!handle);
> +
> + /*
> + * Because we use per-cpu mapping areas shared among the
> + * pools/users, we can't allow mapping in interrupt context
> + * because it can corrupt another users mappings.
> + */
> + BUG_ON(in_interrupt());
> +
> + obj_handle_to_location(handle, &page, &obj_idx);
> + get_zspage_mapping(get_first_page(page), &class_idx, &fg);
> + class = &pool->size_class[class_idx];
> + off = obj_idx_to_offset(page, obj_idx, class->size);
> +
> + area = &get_cpu_var(zs_map_area);
> + area->vm_mm = mm;
> + if (off + class->size <= PAGE_SIZE) {
> + /* this object is contained entirely within a page */
> + area->vm_addr = kmap_atomic(page);
> + return area->vm_addr + off;
> + }
> +
> + /* this object spans two pages */
> + pages[0] = page;
> + pages[1] = get_next_page(page);
> + BUG_ON(!pages[1]);
> +
> + return __zs_map_object(area, pages, off, class->size);
> +}
> +EXPORT_SYMBOL_GPL(zs_map_object);
> +
> +void zs_unmap_object(struct zs_pool *pool, unsigned long handle)
> +{
> + struct page *page;
> + unsigned long obj_idx, off;
> +
> + unsigned int class_idx;
> + enum fullness_group fg;
> + struct size_class *class;
> + struct mapping_area *area;
> +
> + BUG_ON(!handle);
> +
> + obj_handle_to_location(handle, &page, &obj_idx);
> + get_zspage_mapping(get_first_page(page), &class_idx, &fg);
> + class = &pool->size_class[class_idx];
> + off = obj_idx_to_offset(page, obj_idx, class->size);
> +
> + area = &__get_cpu_var(zs_map_area);
> + if (off + class->size <= PAGE_SIZE)
> + kunmap_atomic(area->vm_addr);
> + else {
> + struct page *pages[2];
> +
> + pages[0] = page;
> + pages[1] = get_next_page(page);
> + BUG_ON(!pages[1]);
> +
> + __zs_unmap_object(area, pages, off, class->size);
> + }
> + put_cpu_var(zs_map_area);
> +}
> +EXPORT_SYMBOL_GPL(zs_unmap_object);
> +
> +u64 zs_get_total_size_bytes(struct zs_pool *pool)
> +{
> + int i;
> + u64 npages = 0;
> +
> + for (i = 0; i < ZS_SIZE_CLASSES; i++)
> + npages += pool->size_class[i].pages_allocated;
> +
> + return npages << PAGE_SHIFT;
> +}
> +EXPORT_SYMBOL_GPL(zs_get_total_size_bytes);
> +
> +module_init(zs_init);
> +module_exit(zs_exit);
> +
> +MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_AUTHOR("Nitin Gupta ");
>
--
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/
pampd = ramster_pampd_free(pampd, pool, oid, index, acct);
> if (pampd == NULL)
> return;
> }
> if (is_ephemeral(pool)) {
> - page = zbud_free_and_delist((struct zbudref *)pampd,
> + if (!zero_filled)
&
Hi Linus,
Please pull blackfin updates for 3.6-rc6, one kbuild and a smp build fix.
Thanks,
-Bob
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm
" project in my future. Won't be able to spend any time with
this until at least the weekend :-(.
--
----
Bob Tracy | "I was a beta tester for dirt. They never did
[EMAIL PROTECTED]
ng the radeonfb
driver (built-in, default graphics mode 80x30).
--
--------
Bob Tracy | "I was a beta tester for dirt. They never did
[EMAIL PROTECTED] | get all the bugs out." -
Peter Zijlstra wrote:
> Does: http://lkml.org/lkml/2008/1/28/100
>
> help?
I'll give that a try this evening or tomorrow and let you know.
--
--------
Bob Tracy | "I was a beta tester for dirt. Th
Ivan Kokshaysky wrote:
> On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote:
> > Ivan Kokshaysky wrote:
> > > No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to
> > > to switch to vga console, but I had no time to debug this yet...
> >
Ivan Kokshaysky wrote:
> On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote:
> > Ivan Kokshaysky wrote:
> > > No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to
> > > to switch to vga console, but I had no time to debug this yet...
> >
y and
> the test succeeded by accidend).
>
> Attached is a stripped down LTP test for the problem, uncommenting the
> msync() makes the test succeed.
>
> I would like to hear your opinions on this problems.
>
> --
> Cyril Hrubis
> chru...@suse.cz
--
Regards,
--Bob
--
To
page is volatile.
> */
> int try_to_unmap(struct page *page, enum ttu_flags flags)
> {
> @@ -1665,7 +1769,7 @@ int try_to_unmap(struct page *page, enum ttu_flags
> flags)
> ret = try_to_unmap_anon(page, flags);
> else
> ret = try_t
*page)
> struct swap_info_struct *sis = swap_info[type];
> pgoff_t offset = swp_offset(entry);
>
> + if (!backend_registered)
> + return ret;
> +
> BUG_ON(!PageLocked(page));
> BUG_ON(sis == NULL);
> if (frontswap
gt; [ 1523.750066] 88000d7533f0 fff0 880045f81da8
>> 812361d8
>> [ 1523.750066] 880045f81d98 880048ee9000 8800095b4580
>> 8800095b4580
>> [ 1523.750066] 88001d1cdb00 8800095b45f0 880022a4d630
>> 8
On Mon, Nov 5, 2012 at 11:31 AM, Michel Lespinasse wrote:
> On Sun, Nov 4, 2012 at 6:20 PM, Bob Liu wrote:
>> The loop for each entry of vma->anon_vma_chain in validate_mm() is not
>> protected by anon_vma lock.
>> I think that may be the cause.
>>
>> Michel,
gcc-4.6.3
--
--------
Bob Tracy | "Build a man a fire, he'll be warm for a day. Set
r...@frus.com | a man on fire, he'll be warm for the rest of his
| life." -- David Burge (Iowahawk)
c:435:18: error: 'IREN' undeclared (first use in
this function)
drivers/net/irda/bfin_sir.c:521:11: error: 'IREN' undeclared (first use in
this function)
This patch fix it.
Signed-off-by: Sonic Zhang
Signed-off-by: Bob Liu
---
drivers/net/irda/bfin_sir.c |8
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/major
on the LRU 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 unsubscr
art + PMD_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, &ptl);
-
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:
> 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
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
&
>
> /* 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:
f
> 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: Tomas
ap on x86 and x86-64 and 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.
>
>
fore. How well tested was 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 i
n'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
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
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 2013092
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.
>
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 "uns
;
>>> > 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
handles, not struct page pointers.
>
> 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 dupl
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
obviously. 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/
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
>
A.
> 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/
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.
>>
\
> --
> 1.7.7.6
> --
> 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.t
issue in our internal tree but haven't push to mainline.
I'll update it soon, thank you.
--
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.ke
6594b982f6d5f957c8d72de7658bf8e240c7dfca:
Blackfin: smp: add smp_mb() to keep coherency (2012-10-08 14:36:30 +0800)
Bob Liu (1):
Blackfin: update defconfig for bf609-ezkit
Harald Krapfenbauer (1):
Blackfin: CM-BF537E: Update SPORT support in
de/{ => uapi}/asm/sigcontext.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/siginfo.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/signal.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/stat.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/swab.h (1
On Fri, Nov 30, 2012 at 11:03 PM, Kirill A. Shutemov
wrote:
> From: "Kirill A. Shutemov"
>
> pmd value is stable only with mm->page_table_lock taken. After taking
> the lock we need to check that nobody modified the pmd before change it.
>
> Signed-off-by: Kirill
ANONPAGES);
>
> mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
>
> --
> 1.7.11.7
>
--
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/
Multi place do the same check.
Signed-off-by: Bob Liu
---
mm/huge_memory.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index e575b29..3588fec 100644
--- a/mm/huge_memory.c
+++ b/mm
There are duplicated place using release_pte_pages().
And release_all_pte_pages() can also be removed.
Signed-off-by: Bob Liu
---
mm/huge_memory.c | 37 +++--
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
Introduce hugepage_get_pmd() to simple code.
Signed-off-by: Bob Liu
---
mm/huge_memory.c | 68 ++
1 file changed, 27 insertions(+), 41 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 462d6ea..e575b29 100644
--- a/mm
Introduce mk_huge_pmd() to simple code
Signed-off-by: Bob Liu
---
mm/huge_memory.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 3588fec..9fd1312 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
oc/internal.h | 18 ---
> fs/proc/meminfo.c |1 +
> fs/proc/mmu.c | 60 --
> include/linux/vmalloc.h | 19 +++-
> mm/vmalloc.c| 258
> +--
> 9 files changed,
m/ioremap.c
>> @@ -282,12 +282,7 @@ void iounmap(volatile void __iomem *addr)
>>in parallel. Reuse of the virtual address is prevented by
>>leaving it in the global lists until we're done with it.
>>cpa takes care of the direct mapping
llback path for COW of HZP
>> thp: avoid race on multiple parallel page faults to the same page
>>
>> mm/huge_memory.c | 30 +-
>> 1 file changed, 25 insertions(+), 5 deletions(-)
>
I still saw this bug on 3.7.0-rc8, but it's hard to rep
corrupt
> swapping in such a fashion, so ideas highly welcome. QA people are
> cc'ed, and hopefully I haven't missed anyone else on the cc list.
>
You can take a look at this thread:
[PATCH] mm: fix a regression with HIGHMEM introduced by changeset 7f1290f2f2a4d
http://lkml
> So how about totally reverting the changeset
>> 7f1290f2f2a4d2c3f1b7ce8e87256e052ca23125
>> and I will post another version once I found a cleaner way?
>
> I think fixup_zone_present_pages() are very useful for memory hotplug.
>
I might miss something, but if memory hotp
Hi Michel,
On Wed, Nov 7, 2012 at 11:54 AM, Michel Lespinasse wrote:
> On Tue, Nov 6, 2012 at 12:24 AM, Michel Lespinasse wrote:
>> On Mon, Nov 5, 2012 at 5:41 AM, Michel Lespinasse wrote:
>>> On Sun, Nov 4, 2012 at 8:44 PM, Michel Lespinasse wrote:
>>>> On Su
On Sat, Nov 03, 2012 at 10:24:58AM +0100, Marco Stornelli wrote:
> Removed vmtruncate
>
> Signed-off-by: Marco Stornelli
Thanks!
Acked-by: Bob Copeland
> ---
> fs/omfs/file.c | 22 +++---
> 1 files changed, 15 insertions(+), 7 deletions(-)
On Mon, Nov 05, 2012 at 07:53:13AM -0600, Bob Tracy wrote:
> With digital signature verification support (SIGNATURE, MPILIB) enabled
> on the Alpha platform, I get the following during the MODPOST section of
> the build:
>
> ERROR: "__udiv_qrnnd" [lib/mpi/mpi.ko] undefin
gt; evt->name = "bfin_core_timer";
> evt->rating = 350;
> evt->irq = -1;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
Regards,
--Bob
--
To unsubscribe from th
BUG_ON(sis == NULL);
>> + if (sis->frontswap_map == NULL)
>> + return;
>> + (*frontswap_ops.invalidate_area)(type);
>> + atomic_set(&sis->frontswap_pages, 0);
>> + memset(sis->frontswap_m
v32 zswap]# cat *
0
424057
99538
0
2749448
0
24
60018
16837
[root@ca-dev32 zswap]# cat pool_pages
97372
[root@ca-dev32 zswap]# cat stored_pages
53701
[root@ca-dev32 zswap]#
I think it's unreasonable to use more pool pages than stored pages!
Regards,
-Bob
--
To unsubscribe from this
0.00%) 38073.00 ( 49.23%)
Ops majorfaults-1125M 72458.00 ( 0.00%) 38206.00 ( 47.27%)
Ops majorfaults-1356M 70549.00 ( 0.00%) 37430.00 ( 46.94%)
Regards,
-Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
bud = FIRST;
> + else
> + bud = LAST;
> + goto found;
> + }
> + }
> +
> + /* Couldn't find unbuddied zbud page, create new one */
How about moving zswap_is_full() to here.
if
aults-1356M 66598.00 ( 0.00%) 37123.00 ( 44.26%)
It shows clearly that swaptotal and minorfaults get improved a little
if enabled zswap.
But with the cost that the performance of everything else dropped a lot.
--
Regards,
--Bob
--
To unsubscribe from this list: send the line &
56M 37123.00 ( 0.00%) 37779.00 ( -1.77%)
--
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, Jun 19, 2013 at 10:09 PM, Seth Jennings
wrote:
> On Mon, Jun 17, 2013 at 02:20:05PM +0800, Bob Liu wrote:
>> Hi Seth,
>>
>> On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
>> wrote:
>> > zswap is a thin backend for frontswap that takes pages that ar
On Thu, Jun 20, 2013 at 10:37 AM, Seth Jennings
wrote:
> On Mon, Jun 17, 2013 at 02:20:05PM +0800, Bob Liu wrote:
>> Hi Seth,
>>
>> On Tue, Jun 4, 2013 at 4:33 AM, Seth Jennings
>> wrote:
>> > zswap is a thin backend for frontswap that takes pages that ar
On Thu, Jun 20, 2013 at 10:23 PM, Seth Jennings
wrote:
> On Thu, Jun 20, 2013 at 05:42:04PM +0800, Bob Liu wrote:
>> > Just made a mmtests run of my own and got very different results:
>> >
>>
>> It's strange, I'll update to rc6 and try again.
>>
.
>
> Just a way to sidestep this whole issue. What do you think?
>
> Seth
>
--
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.o
On 06/08/2013 03:45 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 07, 2013 at 12:29:15PM -0700, Konrad Rzeszutek Wilk wrote:
>
> CC-ing Bob.
>
>> Commit 10a7a0771399a57a297fca9615450dbb3f88081a ("xen: tmem: enable Xen
>> tmem shim to be built/loaded as a module"
0
[] security_file_permission+0xd8/0x110
[] rw_verify_area+0x64/0x120
[] vfs_read+0x84/0x1c0
[] SyS_read+0x6c/0xc0
[] entSys+0xa4/0xc0
Code: a75e a53e0008 a55e0010 23de0020 6bfa8001 a55d0158
261dffea
Thanks in advance for an assist in figuring out what's going on here.
--Bob
--
To unsubscribe fro
On Tue, Mar 26, 2013 at 10:16:18PM +1300, Michael Cree wrote:
> On Mon, Mar 25, 2013 at 07:13:35AM -0500, Bob Tracy wrote:
> > Getting lots of these since attempting to upgrade past 3.8.0-rc7. I
> > *don't* think it's a kernel issue at this point, because while older
gt; Otherwise, it could encounter OOM easily.
>
AFAIR, the next step of zswap should be have a modular allocation layer so that
users can choose zsmalloc or zbud to use.
Seth?
--
Regards,
--Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
features.
>> Please, let's promote, expose it to more potential users, receive more
>> complains from them, recruit more contributors and let's enhance.
>>
>
> As this is already used heavily in the field and I am not responsible
> for maintaining it I am not
ng new features.
>> Please, let's promote, expose it to more potential users, receive more
>> complains from them, recruit more contributors and let's enhance.
>>
>
> As this is already used heavily in the field and I am not responsible
> for maintaining it I am not
some hooked driver
> internal logic. VM alreay has a lot information so it would handle multipe
> heterogenous swap more efficenlty like cache hierachy without LRU inversing.
> It could solve current zswap LRU inversing problem generally and help others
> who want to configure multiple swap system as well as zram.
>
>> to diverge will ultimately bite someone in the ass.
>
> Mel, current zram situation is following as.
>
> 1) There are a lot users in the world.
> 2) So, many valuable contributions have been in there.
> 2) The new feature development of zram had stalled because Greg asserted
>he doesn't accept new feature until promote will be done and recently,
>he said he will remove zram in staging if anybody doesn't try to promote
> 3) You are saying zram shouldn't be promote. IOW, zram should go away.
>
> Right? Then, What should we zram developers do?
In my opinion we can do:
1) promote zsmalloc to mm/
2) making zswap can support zsmalloc
3) making zswap can create some fake block device and emulate the same
action of zram
like don't write back.
> What's next step for zram which is really perfect for embedded system?
> We should really lose a chance to enhance zram although fresh zswap
> couldn't replace old zram?
>
> Mel, please consider embedded world although they are very little voice
> in this core subsystem.
>
--
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/
rg/gmane.linux.kernel.mm/104824
I'll pay more attention to the problems of zswap as you mentioned.
> developers that are actually willing to maintain a duel zram/zswap mess
> to make it happen anyway.
>
--
Regards,
-Bob
--
To unsubscribe from this list: send the line &
che although since Dan left I do not believe anyone is
>> planning to try.
>
> I should mention that Bob Liu did some work with zcache recently but is
> now looking like it'll be dropped from staging. I did not look at the
> details and I have no idea if anything else is pla
1 - 100 of 862 matches
Mail list logo
