: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
[wt: Backported to linux-3.10.y: adjusted context]
Signed-off-by: Wenwei Tao <wenwei@alibaba-inc.com>
---
mm/memcontrol.c | 97 -
Heo
Reviewed-by: Tejun Heo
Acked-by: Michal Hocko
Cc: KAMEZAWA Hiroyuki
Cc: Glauber Costa
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[wt: Backported to linux-3.10.y: adjusted context]
Signed-off-by: Wenwei Tao
---
mm/memcontrol.c | 97
2017-07-26 21:44 GMT+08:00 Michal Hocko <mho...@kernel.org>:
> On Wed 26-07-17 21:07:42, Wenwei Tao wrote:
>> From: Wenwei Tao <wenwei@alibaba-inc.com>
>>
>> By removing the child cgroup while the parent cgroup is
>> under reclaim, we could trigger the f
2017-07-26 21:44 GMT+08:00 Michal Hocko :
> On Wed 26-07-17 21:07:42, Wenwei Tao wrote:
>> From: Wenwei Tao
>>
>> By removing the child cgroup while the parent cgroup is
>> under reclaim, we could trigger the following ker
From: Wenwei Tao <wenwei@alibaba-inc.com>
By removing the child cgroup while the parent cgroup is
under reclaim, we could trigger the following kernel panic
on kernel 3.10:
kernel BUG at kernel/cgroup.c:893!
i
From: Wenwei Tao
By removing the child cgroup while the parent cgroup is
under reclaim, we could trigger the following kernel panic
on kernel 3.10:
kernel BUG at kernel/cgroup.c:893!
invalid opcode: [#1] SMP
CPU: 1
Hi,
I open the Transparent huge page and run the system and hit the bug
in huge_memory.c:
static void __split_huge_page_refcount(struct page *page)
.
.
.
/* tail_page->_mapcount cannot change */
Hi,
I open the Transparent huge page and run the system and hit the bug
in huge_memory.c:
static void __split_huge_page_refcount(struct page *page)
.
.
.
/* tail_page->_mapcount cannot change */
Hi,
The original message is somehow determined to be junk mail and
rejected by the system.
Forward this message.
-- Forwarded message --
From: Wenwei Tao <ww.tao0...@gmail.com>
Date: 2016-06-19 10:40 GMT+08:00
Subject: Re: [RFC PATCH 1/3] mm, page_alloc: free HIGHATOMI
Hi,
The original message is somehow determined to be junk mail and
rejected by the system.
Forward this message.
-- Forwarded message --
From: Wenwei Tao
Date: 2016-06-19 10:40 GMT+08:00
Subject: Re: [RFC PATCH 1/3] mm, page_alloc: free HIGHATOMIC page
directly to the allocator
From: Wenwei Tao <ww.tao0...@gmail.com>
We might not want other migrate types pin highatomic pageblock
away since it's reserved for high order use. And also we might
not want reserve high atomic pages out of limit, we can add
check in __free_one_page but this might be costly, so jus
From: Wenwei Tao
We might not want other migrate types pin highatomic pageblock
away since it's reserved for high order use. And also we might
not want reserve high atomic pages out of limit, we can add
check in __free_one_page but this might be costly, so just stop
the merging.
Signed-off
From: Wenwei Tao <ww.tao0...@gmail.com>
The migratetype might get staled, pages might have become highatomic when
we try to free them to the allocator, we might not want to put highatomic
pages into other buddy lists, since they are reserved only for atomic high
order use. And also high
From: Wenwei Tao
The migratetype might get staled, pages might have become highatomic when
we try to free them to the allocator, we might not want to put highatomic
pages into other buddy lists, since they are reserved only for atomic high
order use. And also highatomic pages could have been
From: Wenwei Tao <ww.tao0...@gmail.com>
The migratetype might get staled, pages might have become highatomic when
we try to free them to the allocator, we might not want to put highatomic
pages into other buddy lists, since they are reserved only for atomic high
order use. And also high
From: Wenwei Tao
The migratetype might get staled, pages might have become highatomic when
we try to free them to the allocator, we might not want to put highatomic
pages into other buddy lists, since they are reserved only for atomic high
order use. And also highatomic pages could have been
Hi
Something is wrong with my email, I cannot send the patch out, and
this patch commit title is not complete.
Apologize for the noise.
2016-06-18 19:45 GMT+08:00 Wenwei Tao <linuxtao_...@163.com>:
> From: Wenwei Tao <ww.tao0...@gmail.com>
>
> The migratetype might get sta
Hi
Something is wrong with my email, I cannot send the patch out, and
this patch commit title is not complete.
Apologize for the noise.
2016-06-18 19:45 GMT+08:00 Wenwei Tao :
> From: Wenwei Tao
>
> The migratetype might get staled, pages might have become highatomic when
> we try
From: Wenwei Tao <ww.tao0...@gmail.com>
Some pages might have already been allocated before reserve
the pageblock as HIGHATOMIC. When free these pages, put them
directly to the allocator instead of the pcp lists since they
might have the chance to be merged to high order pages.
Sign
From: Wenwei Tao
Some pages might have already been allocated before reserve
the pageblock as HIGHATOMIC. When free these pages, put them
directly to the allocator instead of the pcp lists since they
might have the chance to be merged to high order pages.
Signed-off-by: Wenwei Tao
---
mm
I think explicit BUG_ON may make the debug easier, since it can point
out the wrong line.
2016-05-30 16:53 GMT+08:00 Michal Hocko <mho...@kernel.org>:
> On Mon 30-05-16 16:45:51, Wenwei Tao wrote:
>> From: Wenwei Tao <ww.tao0...@gmail.com>
>>
>> The mem_cgroup_tr
I think explicit BUG_ON may make the debug easier, since it can point
out the wrong line.
2016-05-30 16:53 GMT+08:00 Michal Hocko :
> On Mon 30-05-16 16:45:51, Wenwei Tao wrote:
>> From: Wenwei Tao
>>
>> The mem_cgroup_tree_per_node allocation might fail,
>> check tha
From: Wenwei Tao <ww.tao0...@gmail.com>
The mem_cgroup_tree_per_node allocation might fail,
check that before continue the memcg init. Since it
is in the init phase, trigger the panic if that failure
happens.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
mm/memcontrol.c |
From: Wenwei Tao
The mem_cgroup_tree_per_node allocation might fail,
check that before continue the memcg init. Since it
is in the init phase, trigger the panic if that failure
happens.
Signed-off-by: Wenwei Tao
---
mm/memcontrol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm
e's gn->lock not
>> the global nvm_lock now.
>>
>> 2016-05-23 20:24 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
>>>
>>> On 05/23/2016 01:05 PM, Wenwei Tao wrote:
>>>>
>>>>
>>>> 2016-05-23 17:16 GMT+08:00 Matias B
It's fine to allow the user to define a device name as long as hold
the global lock and link the targets into a global list but that may
against the idea to move the target management into media mgr.
2016-05-24 22:17 GMT+08:00 Matias Bjørling :
> On 05/23/2016 03:31 PM, Wenwei Tao wrote:
>&
GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 05/23/2016 01:05 PM, Wenwei Tao wrote:
>>
>> 2016-05-23 17:16 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
>>>
>>> On 05/23/2016 11:13 AM, Wenwei Tao wrote:
>>>>
>>>>
>
GMT+08:00 Matias Bjørling :
> On 05/23/2016 01:05 PM, Wenwei Tao wrote:
>>
>> 2016-05-23 17:16 GMT+08:00 Matias Bjørling :
>>>
>>> On 05/23/2016 11:13 AM, Wenwei Tao wrote:
>>>>
>>>>
>>>> From: Wenwei Tao
>>>>
>>&
2016-05-23 17:16 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 05/23/2016 11:13 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao <ww.tao0...@gmail.com>
>>
>> We may create targets with same name on different
>> backend devices, this is not what we want
2016-05-23 17:16 GMT+08:00 Matias Bjørling :
> On 05/23/2016 11:13 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao
>>
>> We may create targets with same name on different
>> backend devices, this is not what we want, so append
>> the device name to target nam
From: Wenwei Tao <ww.tao0...@gmail.com>
When create a target, we check whether the target is
already exist first. If the answer is no, we release
the lock and continue the creation. This cannot prevent
concurrent creation of the same target, so hold the lock
until finish the target cr
From: Wenwei Tao <ww.tao0...@gmail.com>
We may create targets with same name on different
backend devices, this is not what we want, so append
the device name to target name to make the new target
name unique in the system.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
driv
From: Wenwei Tao
When create a target, we check whether the target is
already exist first. If the answer is no, we release
the lock and continue the creation. This cannot prevent
concurrent creation of the same target, so hold the lock
until finish the target creation.
Signed-off-by: Wenwei Tao
From: Wenwei Tao
We may create targets with same name on different
backend devices, this is not what we want, so append
the device name to target name to make the new target
name unique in the system.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/gennvm.c | 13 +++--
1 file changed
Okay, I will rebase it on for-4.8/core.
2016-05-19 20:42 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 05/19/2016 08:38 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao <ww.tao0...@gmail.com>
>>
>> When create a target, we check whether the target i
Okay, I will rebase it on for-4.8/core.
2016-05-19 20:42 GMT+08:00 Matias Bjørling :
> On 05/19/2016 08:38 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao
>>
>> When create a target, we check whether the target is
>> already exist first. If the answer is no, we
That is okay with me.
2016-05-19 20:40 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 05/19/2016 08:38 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao <ww.tao0...@gmail.com>
>>
>> Break the loop when rqd is not null to reduce
>> unnecessary sched
That is okay with me.
2016-05-19 20:40 GMT+08:00 Matias Bjørling :
> On 05/19/2016 08:38 AM, Wenwei Tao wrote:
>>
>> From: Wenwei Tao
>>
>> Break the loop when rqd is not null to reduce
>> unnecessary schedule.
>>
>> Signed-off-by: Wenwei Tao
>&
From: Wenwei Tao <ww.tao0...@gmail.com>
Break the loop when rqd is not null to reduce
unnecessary schedule.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/rrpc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/
From: Wenwei Tao <ww.tao0...@gmail.com>
When create a target, we check whether the target is
already exist first. If the answer is no, we release
the lock and continue the creation. This cannot prevent
concurrent creation of the same target, so hold the lock
until finish the target cr
From: Wenwei Tao
When create a target, we check whether the target is
already exist first. If the answer is no, we release
the lock and continue the creation. This cannot prevent
concurrent creation of the same target, so hold the lock
until finish the target creation.
Signed-off-by: Wenwei Tao
From: Wenwei Tao
Break the loop when rqd is not null to reduce
unnecessary schedule.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 2103e97..2915e39 100644
--- a/drivers
From: Wenwei Tao <ww.tao0...@gmail.com>
When create css failed, before call css_free_rcu_fn,
we remove the css id and exit the percpu_ref, but we
will do these again in css_free_work_fn, so they are redundant.
Especially the css id, that would cause problem if we
remove it twice, since
From: Wenwei Tao
When create css failed, before call css_free_rcu_fn,
we remove the css id and exit the percpu_ref, but we
will do these again in css_free_work_fn, so they are redundant.
Especially the css id, that would cause problem if we
remove it twice, since it may be assigned to another
the bound of target's own intead of global device's.
In rrpc_block_map_update, we should use the global
physcical address to compare with the one in trans_map,
since we store the global value in it.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/rrpc.
Since we mainly use soffset in device sector size, we store
that value in rrpc->soffset to reduce doing "(ilog2(dev->sec_size) - 9)".
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/rrpc.c | 17 ++---
1 file changed, 10 insertions(+), 7 de
Calculate rrpc total blocks and sectors up front, make sense
to use them. For example, we use rrpc->nr_sects to calculate rrpc
area size, but it makes no sense if we don't initialize it up front,
since it would be zero until we finish rrpc luns init.
Signed-off-by: Wenwei Tao <w
the bound of target's own intead of global device's.
In rrpc_block_map_update, we should use the global
physcical address to compare with the one in trans_map,
since we store the global value in it.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 39 ++-
1
Since we mainly use soffset in device sector size, we store
that value in rrpc->soffset to reduce doing "(ilog2(dev->sec_size) - 9)".
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/
Calculate rrpc total blocks and sectors up front, make sense
to use them. For example, we use rrpc->nr_sects to calculate rrpc
area size, but it makes no sense if we don't initialize it up front,
since it would be zero until we finish rrpc luns init.
Signed-off-by: Wenwei Tao
---
driv
Okay, I'll send a patch to cover that change.
2016-03-31 17:11 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 03/30/2016 04:28 PM, Wenwei Tao wrote:
>>
>> Since every target now has their own logical address area,
>> we should deal trans_map and rev_trans_map with
Okay, I'll send a patch to cover that change.
2016-03-31 17:11 GMT+08:00 Matias Bjørling :
> On 03/30/2016 04:28 PM, Wenwei Tao wrote:
>>
>> Since every target now has their own logical address area,
>> we should deal trans_map and rev_trans_map with relative
>&
This is okay with me.
By the way, why don't you like (sector_t)dev->sec_size *
dev->sec_per_lun * rrpc->nr_luns, the change seems smaller?
2016-03-31 18:07 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 03/31/2016 11:51 AM, Wenwei Tao wrote:
>>
>> This could be
This is okay with me.
By the way, why don't you like (sector_t)dev->sec_size *
dev->sec_per_lun * rrpc->nr_luns, the change seems smaller?
2016-03-31 18:07 GMT+08:00 Matias Bjørling :
> On 03/31/2016 11:51 AM, Wenwei Tao wrote:
>>
>> This could be work, but
ero by mistake. If we move rrpc_area_init
call under the rrpc_luns_init call instead, we need a way to avoid it.
2016-03-31 16:57 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
>
>
> On 03/31/2016 10:31 AM, Wenwei Tao wrote:
>>
>> 2016-03-30 22:28 GMT+08:00 We
ero by mistake. If we move rrpc_area_init
call under the rrpc_luns_init call instead, we need a way to avoid it.
2016-03-31 16:57 GMT+08:00 Matias Bjørling :
>
>
> On 03/31/2016 10:31 AM, Wenwei Tao wrote:
>>
>> 2016-03-30 22:28 GMT+08:00 Wenwei Tao :
>>>
>>&g
2016-03-30 22:28 GMT+08:00 Wenwei Tao <ww.tao0...@gmail.com>:
> rrpc->nr_sects is calculated after rrpc init luns succeeds,
> before that the value of rrpc->nr_sects is zero, so we cannot
> use it to calcuate rrpc area size, we use rrpc->nr_luns instead.
>
> Sign
2016-03-30 22:28 GMT+08:00 Wenwei Tao :
> rrpc->nr_sects is calculated after rrpc init luns succeeds,
> before that the value of rrpc->nr_sects is zero, so we cannot
> use it to calcuate rrpc area size, we use rrpc->nr_luns instead.
>
> Signed-off-by: Wenwei Tao
> ---
rrpc->nr_sects is calculated after rrpc init luns succeeds,
before that the value of rrpc->nr_sects is zero, so we cannot
use it to calcuate rrpc area size, we use rrpc->nr_luns instead.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/rrpc.c | 2 +-
1
rrpc->nr_sects is calculated after rrpc init luns succeeds,
before that the value of rrpc->nr_sects is zero, so we cannot
use it to calcuate rrpc area size, we use rrpc->nr_luns instead.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 2 +-
1 file changed, 1 insertion(+), 1
Since every target now has their own logical address area,
we should deal trans_map and rev_trans_map with relative
logical address instead of the global one.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/rrpc.c | 12
1 file changed, 8 insertions
Since every target now has their own logical address area,
we should deal trans_map and rev_trans_map with relative
logical address instead of the global one.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git
I notice that sysfs already have lun information exposed, we only need
to add some more,
2016-03-21 18:27 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 03/19/2016 05:58 PM, Wenwei Tao wrote:
>>
>> Export per lun information to user, let the user
>> know mo
I notice that sysfs already have lun information exposed, we only need
to add some more,
2016-03-21 18:27 GMT+08:00 Matias Bjørling :
> On 03/19/2016 05:58 PM, Wenwei Tao wrote:
>>
>> Export per lun information to user, let the user
>> know more detail information ab
to test_and_set_bit instead of 0.
2016-03-21 18:25 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 03/20/2016 06:51 AM, Wenwei Tao wrote:
>>
>> Divide the target's global reverse translation map into per lun,
>> to prepare support for the non-continuous lun target creation.
>
to test_and_set_bit instead of 0.
2016-03-21 18:25 GMT+08:00 Matias Bjørling :
> On 03/20/2016 06:51 AM, Wenwei Tao wrote:
>>
>> Divide the target's global reverse translation map into per lun,
>> to prepare support for the non-continuous lun target creation.
>>
>> Signed-off-by:
Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
Changes since v1
-fix merge/rebase mistake in rrpc_block_map_update().
-remove variables poffset and lun_
Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.
Signed-off-by: Wenwei Tao
---
Changes since v1
-fix merge/rebase mistake in rrpc_block_map_update().
-remove variables poffset and lun_offset in rrpc structure
since
,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
Changes since v4
-fix target creation fail.
-move code concerning the per-lun reverse translation
map to a new patch.
Changes since v3
-limit list luns to 768, thus we don't go
Export per lun information to user, let the user
know more detail information about underlying device.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/core.c | 59 ++-
drivers/lightnvm/gennvm.c
,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao
---
Changes since v4
-fix target creation fail.
-move code concerning the per-lun reverse translation
map to a new patch.
Changes since v3
-limit list luns to 768, thus we don't go
above a single memory page.
-move
Export per lun information to user, let the user
know more detail information about underlying device.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 59 ++-
drivers/lightnvm/gennvm.c | 34 +
include/linux
Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/rrpc.c | 183 +++
drivers/lightnvm/rrpc.h
Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 183 +++
drivers/lightnvm/rrpc.h | 7 +-
include/linux
goto err;
- }
I will include the changes you mentioned in the next version.
Thanks.
2016-02-18 20:35 GMT+08:00 Javier González <j...@lightnvm.io>:
>> On 16 Feb 2016, at 12:28, Wenwei Tao <ww.tao0...@gmail.com> wrote:
>>
>> When create
goto err;
- }
I will include the changes you mentioned in the next version.
Thanks.
2016-02-18 20:35 GMT+08:00 Javier González :
>> On 16 Feb 2016, at 12:28, Wenwei Tao wrote:
>>
>> When create a target, we specify the begin lunid and
>> the en
After register null_blk devices into lightnvm, we forget
to add these devices to the the nullb_list, makes them
invisible to the null_blk driver.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/block/null_blk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
After register null_blk devices into lightnvm, we forget
to add these devices to the the nullb_list, makes them
invisible to the null_blk driver.
Signed-off-by: Wenwei Tao
---
drivers/block/null_blk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/block/null_blk.c
Export per lun information to user, let the user
know more detail information about underlying device.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/core.c | 59 ++-
drivers/lightnvm/gennvm.c
Export per lun information to user, let the user
know more detail information about underlying device.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 59 ++-
drivers/lightnvm/gennvm.c | 34 +
include/linux
,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
Changes since v3
-limit list luns to 768, thus we don't go
above a single memory page.
-move NVM_DEV_FREE_LUNS to its own patch and
rename it to NVM_DEV_LUNS_STATUS.
-insert and delet
,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao
---
Changes since v3
-limit list luns to 768, thus we don't go
above a single memory page.
-move NVM_DEV_FREE_LUNS to its own patch and
rename it to NVM_DEV_LUNS_STATUS.
-insert and delete some lines to increase
okay, I agree it's good to export these information to user. Will
include these changes in the next version.
2016-02-05 20:55 GMT+08:00 Matias Bjørling :
> On 02/05/2016 03:42 AM, Wenwei Tao wrote:
>> When create a target, we specify the begin lunid and
>> the end lunid, and get th
Forgot to do that.
Thanks for fixing my mistake.
2016-02-05 19:59 GMT+08:00 Matias Bjørling :
> On 02/04/2016 12:34 PM, Wenwei Tao wrote:
>> Add a bitmap of luns to indicate the status
>> of luns: inuse/available. When create targets
>> do the necessary check to
Forgot to do that.
Thanks for fixing my mistake.
2016-02-05 19:59 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 02/04/2016 12:34 PM, Wenwei Tao wrote:
>> Add a bitmap of luns to indicate the status
>> of luns: inuse/available. When create targets
>> do the necessar
okay, I agree it's good to export these information to user. Will
include these changes in the next version.
2016-02-05 20:55 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 02/05/2016 03:42 AM, Wenwei Tao wrote:
>> When create a target, we specify the begin lunid and
>> t
,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao
---
Changes since v2
-rebase on for-next branch
-move luns bitmap to PATCH 2
-remove the logic to dynamically select another lun than
the one requested
-implement lunid list in the lnvm ioctl interface
Changes
the targets on the device might use
the same logical addresses cause incorrect
information in the device's l2p table.
Signed-off-by: Wenwei Tao
---
Changes since v2:
-rebase on for-next branch
-make the list increase by area->begin
Changes since v1:
-rename some variables
-add parenthe
Add a bitmap of luns to indicate the status
of luns: inuse/available. When create targets
do the necessary check to avoid allocating luns
that are already allocated.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 5
drivers/lightnvm/gennvm.c | 18 +++
drivers
Add a bitmap of luns to indicate the status
of luns: inuse/available. When create targets
do the necessary check to avoid allocating luns
that are already allocated.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/core.c | 5
drivers/lightnvm/gennvm.
the targets on the device might use
the same logical addresses cause incorrect
information in the device's l2p table.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
Changes since v2:
-rebase on for-next branch
-make the list increase by area->begin
Changes since v1:
-rename some varia
,
thus we can improve the backend device's space utilization.
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
Changes since v2
-rebase on for-next branch
-move luns bitmap to PATCH 2
-remove the logic to dynamically select another lun than
the one requested
-implement lunid list in the lnvm
OK, I see. Will include these changes in next version.
2016-01-28 17:09 GMT+08:00 Matias Bjørling :
> On 01/28/2016 09:50 AM, Wenwei Tao wrote:
>> 2016-01-27 17:44 GMT+08:00 Matias Bjørling :
>>> On 01/26/2016 01:33 PM, Wenwei Tao wrote:
>>>> When create a targ
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index d8c7595..307db1e 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -300,8 +300,10 @@ static int
2016-01-27 17:44 GMT+08:00 Matias Bjørling :
> On 01/26/2016 01:33 PM, Wenwei Tao wrote:
>> When create a target, we specify the begin lunid and
>> the end lunid, and get the corresponding continuous
>> luns from media manager, if one of the luns is not free,
>> we
2016-01-27 17:44 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 01/26/2016 01:33 PM, Wenwei Tao wrote:
>> When create a target, we specify the begin lunid and
>> the end lunid, and get the corresponding continuous
>> luns from media manager, if one of the lun
Signed-off-by: Wenwei Tao <ww.tao0...@gmail.com>
---
drivers/lightnvm/rrpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index d8c7595..307db1e 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@
OK, I see. Will include these changes in next version.
2016-01-28 17:09 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
> On 01/28/2016 09:50 AM, Wenwei Tao wrote:
>> 2016-01-27 17:44 GMT+08:00 Matias Bjørling <m...@lightnvm.io>:
>>> On 01/26/2016 01:33 PM, Wenw
to rrpc,
but the code above indeed make me confuse about the sec and page
thing.
Hope I'm not misunderstand the code.
ps: I'm not an expert on flash, if the confusion is caused by lack of
knowledge about flash, pleas let me know.
2016-01-27 21:26 GMT+08:00 Matias Bjørling :
> On 01/27/2016 01:
2016-01-27 17:36 GMT+08:00 Matias Bjørling :
> On 01/27/2016 07:06 AM, Wenwei Tao wrote:
>> Thanks.
>>
>> 2016-01-27 13:52 GMT+08:00 Matias Bjørling :
>>> On 01/27/2016 03:21 AM, Wenwei Tao wrote:
>>>>
>>>> Yes, It's a spelling mistake,
1 - 100 of 226 matches
Mail list logo
