Re: [PATCH] remove no longer use of pdflush interface

[Fengguang Wu]

On Mon, Jun 04, 2012 at 09:25:53PM +0800, Wanpeng Li wrote:
> On Mon, Jun 04, 2012 at 08:53:56PM +0800, Fengguang Wu wrote:
> >Hi Wanpeng,
> >
> >On Mon, Jun 04, 2012 at 08:40:42PM +0800, Wanpeng Li wrote:
> >> From: Wanpeng Li <liwp@xxxxxxxxxxxxxxxxxx>
> >> 
> >> remove no longer use of pdflush interface nr_pdflush_threads.
> >
> >The patch looks good in itself: the nr_pdflush_threads takes no effect
> >for many of the recent kernels. But what's the normal process of
> >interface removal?  Shall we carry some warning printk for some time
> >first or whatever?
> 
> Hi, Fengguang,
> 
> I also want to add an interface of nr_bdi_writeback_threads to statistic
> how many flusher-x:y currently running, do you think it is a good idea?

Hmm, we try to avoid adding interfaces without a good reason. What
would be the use case? Are there real user demands for this at all?

Thanks,
Fengguang

> >> Signed-off-by: Wanpeng Li <liwp@xxxxxxxxxxxxxxxxxx>
> >> ---
> >>  Documentation/sysctl/vm.txt |   11 -----------
> >>  fs/fs-writeback.c           |    5 -----
> >>  include/linux/writeback.h   |    5 -----
> >>  kernel/sysctl.c             |    7 -------
> >>  4 files changed, 28 deletions(-)
> >> 
> >> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> >> index 96f0ee8..71c17d2 100644
> >> --- a/Documentation/sysctl/vm.txt
> >> +++ b/Documentation/sysctl/vm.txt
> >> @@ -42,7 +42,6 @@ Currently, these files are in /proc/sys/vm:
> >>  - mmap_min_addr
> >>  - nr_hugepages
> >>  - nr_overcommit_hugepages
> >> -- nr_pdflush_threads
> >>  - nr_trim_pages         (only if CONFIG_MMU=n)
> >>  - numa_zonelist_order
> >>  - oom_dump_tasks
> >> @@ -426,16 +425,6 @@ See Documentation/vm/hugetlbpage.txt
> >>  
> >>  ==============================================================
> >>  
> >> -nr_pdflush_threads
> >> -
> >> -The current number of pdflush threads.  This value is read-only.
> >> -The value changes according to the number of dirty pages in the system.
> >> -
> >> -When necessary, additional pdflush threads are created, one per second, up to
> >> -nr_pdflush_threads_max.
> >> -
> >> -==============================================================
> >> -
> >>  nr_trim_pages
> >>  
> >>  This is available only on NOMMU kernels.
> >> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> >> index 539f36c..30ddb8a 100644
> >> --- a/fs/fs-writeback.c
> >> +++ b/fs/fs-writeback.c
> >> @@ -52,11 +52,6 @@ struct wb_writeback_work {
> >>  	struct completion *done;	/* set if the caller waits */
> >>  };
> >>  
> >> -/*
> >> - * We don't actually have pdflush, but this one is exported though /proc...
> >> - */
> >> -int nr_pdflush_threads;
> >> -
> >>  /**
> >>   * writeback_in_progress - determine whether there is writeback in progress
> >>   * @bdi: the device's backing_dev_info structure.
> >> diff --git a/include/linux/writeback.h b/include/linux/writeback.h
> >> index a2b84f5..13b5df7 100644
> >> --- a/include/linux/writeback.h
> >> +++ b/include/linux/writeback.h
> >> @@ -193,9 +193,4 @@ void tag_pages_for_writeback(struct address_space *mapping,
> >>  
> >>  void account_page_redirty(struct page *page);
> >>  
> >> -/* pdflush.c */
> >> -extern int nr_pdflush_threads;	/* Global so it can be exported to sysctl
> >> -				   read-only. */
> >> -
> >> -
> >>  #endif		/* WRITEBACK_H */
> >> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> >> index 4ab1187..e257b61 100644
> >> --- a/kernel/sysctl.c
> >> +++ b/kernel/sysctl.c
> >> @@ -1095,13 +1095,6 @@ static struct ctl_table vm_table[] = {
> >>  		.extra1		= &zero,
> >>  	},
> >>  	{
> >> -		.procname	= "nr_pdflush_threads",
> >> -		.data		= &nr_pdflush_threads,
> >> -		.maxlen		= sizeof nr_pdflush_threads,
> >> -		.mode		= 0444 /* read-only*/,
> >> -		.proc_handler	= proc_dointvec,
> >> -	},
> >> -	{
> >>  		.procname	= "swappiness",
> >>  		.data		= &vm_swappiness,
> >>  		.maxlen		= sizeof(vm_swappiness),
> >> -- 
> >> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/