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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A1287FC.9020401@rsk.demon.co.uk>
Date:	Tue, 19 May 2009 11:20:44 +0100
From:	Richard Kennedy <richard@....demon.co.uk>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	chris.mason@...cle.com, david@...morbit.com, hch@...radead.org,
	akpm@...ux-foundation.org, jack@...e.cz,
	yanmin_zhang@...ux.intel.com
Subject: Re: [PATCH 02/11] writeback: switch to per-bdi threads for flushing
 data

Jens Axboe wrote:
> This gets rid of pdflush for bdi writeout and kupdated style cleaning.
> <snip>
> index 2296ff4..76269f8 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -541,7 +530,7 @@ static void balance_dirty_pages(struct address_space *mapping)
>  		 * been flushed to permanent storage.
>  		 */
>  		if (bdi_nr_reclaimable) {
> -			writeback_inodes(&wbc);
> +			generic_sync_bdi_inodes(NULL, &wbc);
>  			pages_written += write_chunk - wbc.nr_to_write;
>  			get_dirty_limits(&background_thresh, &dirty_thresh,
>  				       &bdi_thresh, bdi);
> @@ -592,7 +581,7 @@ static void balance_dirty_pages(struct address_space *mapping)
>  			(!laptop_mode && (global_page_state(NR_FILE_DIRTY)
>  					  + global_page_state(NR_UNSTABLE_NFS)
>  					  > background_thresh)))
> -		pdflush_operation(background_writeout, 0);
> +		bdi_start_writeback(bdi, NULL, 0);
>  }
>  
Hi Jens,

I'm interested in this slight change of behaviour, when over the
background dirty limit background_writeout will write any dirty pages
while bdi_start_writeout writes only pages for the current bdi. Are
there any benefits in making this change?

Thinking about the case of 2 apps writing to different bdis. When app A
stops writing, then next time app B goes over the background dirty
threshold it will only be able to write its own pages, leaving any from
app A dirty until they reach their age limit.

So we may be keeping dirty pages for the app that's finished longer than
necessary. Keeping pages for a finished app while flushing pages from a
running app seems a bit strange. I guess this is an odd corner case and
may not be worth worrying about, but I'd be interested to hear what you
think.

Do you think your new code will require any changes to the per bdi dirty
limits? It may be informative & interesting to run some tests writing to
fast & slow devices at the same time.

regards
Richard





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ