| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4e84d84d-34e6-5e1d-f0d8-fe20845f4987@kernel.org>
Date: Fri, 4 Nov 2016 23:51:46 +0800
From: Chao Yu <chao@...nel.org>
To: Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <yuchao0@...wei.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 2/3] f2fs: use __set_page_dirty_nobuffers
directly
On 2016/11/4 1:57, Jaegeuk Kim wrote:
> On Thu, Nov 03, 2016 at 05:50:34PM +0800, Chao Yu wrote:
>> On 2016/11/3 1:23, Jaegeuk Kim wrote:
>>> On Wed, Nov 02, 2016 at 03:34:32PM +0800, Chao Yu wrote:
>>>> Hi Jaegeuk,
>>>>
>>>> On 2016/10/21 10:28, Jaegeuk Kim wrote:
>>>>> This patch replaces the copied code with original generic function.
>>>>
>>>> Will we plan to do further enhance inside f2fs_set_page_dirty_nobuffers, if we
>>>> don't it's better revert fe76b796fc5194cc3d57265002e3a748566d073f, as we don't
>>>> need to wrap __set_page_dirty_nobuffers.
>>>
>>> Urg. I was confused something here.
>>> Please ignore this patch. I won't merge this patch.
>>
>> Why? isn't __set_page_dirty_nobuffers more fit for f2fs' non-buffer management?
>
> For a while ago, when I tried to improve the performance on pmem, I could hit
> that __set_page_dirty_buffers() slightly improved the bandwidth comparing to
> __set_page_dirty_nobuffers().
>
> When referencing the below comment written in __set_page_dirty_nobuffers(), it
> seems I could get that by adopting "top-down" approach instead of "bottom-up",
> which avoids lock contention as I guess. I couldn't do deep investigation on it
> though.
>
> /*
> * For address_spaces which do not use buffers. Just tag the page as dirty in
> * its radix tree.
> *
> * This is also used when a single buffer is being dirtied: we want to set the
> * page dirty in that case, but not all the buffers. This is a "bottom-up"
> * dirtying, whereas __set_page_dirty_buffers() is a "top-down" dirtying.
> *
> * The caller must ensure this doesn't race with truncation. Most will simply
> * hold the page lock, but e.g. zap_pte_range() calls with the page mapped and
> * the pte lock held, which also locks out truncation.
> */
>
> So, I measured the performance again with fxmark on ramdisk, 8 cores, DWAL,
> bufferedio case. I got 2683158 works/sec w/ "top-down" over 2512609 works/sec w/
> "bottom-up".
Thanks for letting me know the history, f2fs_set_page_dirty_nobuffers and
__set_page_dirty_nobuffers are almost the same except
f2fs_set_page_dirty_nobuffers tries to grab mapping::private_lock additionally.
Maybe holding the private_lock does help the performance on pmem which I can't
explain why it happens now...
Thanks,
>
> Thanks,
>
>>
>> Thanks,
>>
>>>
>>>> BTW, does the original patch make memory cgroup functionality problematic?
>>>
>>> I don't think there is a problem, since I just copied __set_page_dirty_buffers()
>>> except page_has_buffers' stuffs.
>>>
>>> Thank you for pointing this out. :)
>>>
>>>>
>>>> Thanks,
>>>>
>>>>>
>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@...nel.org>
>>>>> ---
>>>>> fs/f2fs/data.c | 29 -----------------------------
>>>>> fs/f2fs/f2fs.h | 6 +++++-
>>>>> 2 files changed, 5 insertions(+), 30 deletions(-)
>>>>>
>>>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>>>> index 68edb47..3954315 100644
>>>>> --- a/fs/f2fs/data.c
>>>>> +++ b/fs/f2fs/data.c
>>>>> @@ -1801,35 +1801,6 @@ int f2fs_release_page(struct page *page, gfp_t wait)
>>>>> return 1;
>>>>> }
>>>>>
>>>>> -/*
>>>>> - * This was copied from __set_page_dirty_buffers which gives higher performance
>>>>> - * in very high speed storages. (e.g., pmem)
>>>>> - */
>>>>> -void f2fs_set_page_dirty_nobuffers(struct page *page)
>>>>> -{
>>>>> - struct address_space *mapping = page->mapping;
>>>>> - unsigned long flags;
>>>>> -
>>>>> - if (unlikely(!mapping))
>>>>> - return;
>>>>> -
>>>>> - spin_lock(&mapping->private_lock);
>>>>> - lock_page_memcg(page);
>>>>> - SetPageDirty(page);
>>>>> - spin_unlock(&mapping->private_lock);
>>>>> -
>>>>> - spin_lock_irqsave(&mapping->tree_lock, flags);
>>>>> - WARN_ON_ONCE(!PageUptodate(page));
>>>>> - account_page_dirtied(page, mapping);
>>>>> - radix_tree_tag_set(&mapping->page_tree,
>>>>> - page_index(page), PAGECACHE_TAG_DIRTY);
>>>>> - spin_unlock_irqrestore(&mapping->tree_lock, flags);
>>>>> - unlock_page_memcg(page);
>>>>> -
>>>>> - __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
>>>>> - return;
>>>>> -}
>>>>> -
>>>>> static int f2fs_set_data_page_dirty(struct page *page)
>>>>> {
>>>>> struct address_space *mapping = page->mapping;
>>>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>>>>> index 168f939..b66a04c 100644
>>>>> --- a/fs/f2fs/f2fs.h
>>>>> +++ b/fs/f2fs/f2fs.h
>>>>> @@ -1960,6 +1960,11 @@ static inline unsigned long f2fs_find_next_bit(const void *addr,
>>>>> return find_next_bit(addr, size, offset + 2);
>>>>> }
>>>>>
>>>>> +static inline void f2fs_set_page_dirty_nobuffers(struct page *page)
>>>>> +{
>>>>> + __set_page_dirty_nobuffers(page);
>>>>> +}
>>>>> +
>>>>> #define get_inode_mode(i) \
>>>>> ((is_inode_flag_set(i, FI_ACL_MODE)) ? \
>>>>> (F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
>>>>> @@ -2200,7 +2205,6 @@ struct page *get_new_data_page(struct inode *, struct page *, pgoff_t, bool);
>>>>> int do_write_data_page(struct f2fs_io_info *);
>>>>> int f2fs_map_blocks(struct inode *, struct f2fs_map_blocks *, int, int);
>>>>> int f2fs_fiemap(struct inode *inode, struct fiemap_extent_info *, u64, u64);
>>>>> -void f2fs_set_page_dirty_nobuffers(struct page *);
>>>>> void f2fs_invalidate_page(struct page *, unsigned int, unsigned int);
>>>>> int f2fs_release_page(struct page *, gfp_t);
>>>>> #ifdef CONFIG_MIGRATION
>>>>>
>>>
>>> .
>>>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
Powered by blists - more mailing lists