Hi Jaegeuk,
On 2017/1/6 10:42, Jaegeuk Kim wrote:
> Hi Chao,
>
> On 01/06, Chao Yu wrote:
>> On 2017/1/6 3:46, Jaegeuk Kim wrote:
>>> On 01/05, Chao Yu wrote:
On 2017/1/4 17:29, Chao Yu wrote:
> On 2016/12/31 2:51, Jaegeuk Kim wrote:
>> This patch relaxes async discard commands to av
Hi Chao,
On 01/06, Chao Yu wrote:
> On 2017/1/6 3:46, Jaegeuk Kim wrote:
> > On 01/05, Chao Yu wrote:
> >> On 2017/1/4 17:29, Chao Yu wrote:
> >>> On 2016/12/31 2:51, Jaegeuk Kim wrote:
> This patch relaxes async discard commands to avoid waiting its end_io
> during
> checkpoint.
>
On 2017/1/6 3:46, Jaegeuk Kim wrote:
> On 01/05, Chao Yu wrote:
>> On 2017/1/4 17:29, Chao Yu wrote:
>>> On 2016/12/31 2:51, Jaegeuk Kim wrote:
This patch relaxes async discard commands to avoid waiting its end_io
during
checkpoint.
Instead of waiting them during checkpoint, it
OK, so I've checked the open coded implementations and converted most of
them. There are few which are either confused and need some special
handling or need double checking.
I can fold this into the original patch or keep it as a separate patch.
Whatever works better for others.
---
>From 72a8493
On 01/02/2017 02:37 PM, Michal Hocko wrote:
> From: Michal Hocko
>
> Using kmalloc with the vmalloc fallback for larger allocations is a
> common pattern in the kernel code. Yet we do not have any common helper
> for that and so users have invented their own helpers. Some of them are
> really crea
From: Michal Hocko
Using kmalloc with the vmalloc fallback for larger allocations is a
common pattern in the kernel code. Yet we do not have any common helper
for that and so users have invented their own helpers. Some of them are
really creative when doing so. Let's just add kv[mz]alloc and make
While checking opencoded users I've encountered that vhost code would
really like to use kvmalloc with __GFP_REPEAT [1] so the following patch
adds support for __GFP_REPEAT and converts both vhost users.
So currently I am sitting on 3 patches. I will wait for more feedback -
especially about poten
In the small discard case, when se->valid_blocks is zero, the add_discard_addrs
will directly return without __add_discard_entry. This will cause the file
delete have no small discard. The case is like this:
1. Allocate free 2M segment
2. Write a file (size n blocks < 512) in that 2M segment, se->
On Mon 02-01-17 07:55:22, Joe Perches wrote:
> On Mon, 2017-01-02 at 14:37 +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Using kmalloc with the vmalloc fallback for larger allocations is a
> > common pattern in the kernel code. Yet we do not have any common helper
> > for that and so
On Mon, 2017-01-02 at 14:37 +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> Using kmalloc with the vmalloc fallback for larger allocations is a
> common pattern in the kernel code. Yet we do not have any common helper
> for that and so users have invented their own helpers. Some of them are
>
On Tue 03-01-17 11:23:04, Vlastimil Babka wrote:
> On 01/02/2017 02:37 PM, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Using kmalloc with the vmalloc fallback for larger allocations is a
> > common pattern in the kernel code. Yet we do not have any common helper
> > for that and so users h
Hi Chao,
On 01/05, Chao Yu wrote:
> Hi Jaegeuk,
>
> I can see patch named ("f2fs: call f2fs_wait_all_discard_bio for an error
> case")
> was merged in dev-test, but I think it's no needed to change error case
> handling
> like this since f2fs_wait_all_discard_bio should always be called after
>
On 01/05, Chao Yu wrote:
> On 2017/1/4 17:29, Chao Yu wrote:
> > On 2016/12/31 2:51, Jaegeuk Kim wrote:
> >> This patch relaxes async discard commands to avoid waiting its end_io
> >> during
> >> checkpoint.
> >> Instead of waiting them during checkpoint, it will be done when actually
> >> reusin
Hi Jaegeuk,
I can see patch named ("f2fs: call f2fs_wait_all_discard_bio for an error case")
was merged in dev-test, but I think it's no needed to change error case handling
like this since f2fs_wait_all_discard_bio should always be called after
clear_prefree_segments.
Thanks,
On 2017/1/5 11:19,
14 matches
Mail list logo
