All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] JFFS2: Prevent CPU starvation during garbage collection.
@ 2015-08-05  4:40 Mark Tomlinson
  2015-08-07 17:21 ` Brian Norris
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Tomlinson @ 2015-08-05  4:40 UTC (permalink / raw)
  To: linux-mtd; +Cc: Mark Tomlinson

The JFFS2 garbage collection checks every file on the system for correct
checksums and cleaning up anything that it needs to. It sleeps for 50ms
between each file, but within each file it remains busy.

As far as I can tell, there is no reason to not reschedule while checking a
file, by putting a cond_resched() inside jfffs2_build_inode_fragtree(). In
fact, jffs2_get_inode_nodes() will call cond_resched(), which is done
immediately before jffs2_build_inode_fragtree().

With this extra cond_resched() between reading file blocks, there is a
dramatic improvement in latency for any processes which are running during
this initial garbage collection phase.

Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
---
 fs/jffs2/readinode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
index 28e0aab..78c526a 100644
--- a/fs/jffs2/readinode.c
+++ b/fs/jffs2/readinode.c
@@ -536,6 +536,7 @@ static int jffs2_build_inode_fragtree(struct jffs2_sb_info *c,
 				jffs2_free_tmp_dnode_info(this);
 			}
 			this = vers_next;
+			cond_resched();
 		}
 	}
 	return 0;
-- 
2.5.0

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] JFFS2: Prevent CPU starvation during garbage collection.
  2015-08-05  4:40 [PATCH] JFFS2: Prevent CPU starvation during garbage collection Mark Tomlinson
@ 2015-08-07 17:21 ` Brian Norris
  2015-08-09 22:24   ` Mark Tomlinson
  0 siblings, 1 reply; 3+ messages in thread
From: Brian Norris @ 2015-08-07 17:21 UTC (permalink / raw)
  To: Mark Tomlinson; +Cc: linux-mtd, David Woodhouse

+ David

I'm not maintaining JFFS2, but if it's exceedingly obvious (this patch
might qualify), I might take patches.

On Wed, Aug 05, 2015 at 04:40:30PM +1200, Mark Tomlinson wrote:
> The JFFS2 garbage collection checks every file on the system for correct
> checksums and cleaning up anything that it needs to. It sleeps for 50ms
> between each file, but within each file it remains busy.
> 
> As far as I can tell, there is no reason to not reschedule while checking a
> file, by putting a cond_resched() inside jfffs2_build_inode_fragtree(). In
> fact, jffs2_get_inode_nodes() will call cond_resched(), which is done
> immediately before jffs2_build_inode_fragtree().
> 
> With this extra cond_resched() between reading file blocks, there is a
> dramatic improvement in latency for any processes which are running during
> this initial garbage collection phase.
> 
> Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
> ---
>  fs/jffs2/readinode.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
> index 28e0aab..78c526a 100644
> --- a/fs/jffs2/readinode.c
> +++ b/fs/jffs2/readinode.c
> @@ -536,6 +536,7 @@ static int jffs2_build_inode_fragtree(struct jffs2_sb_info *c,
>  				jffs2_free_tmp_dnode_info(this);
>  			}
>  			this = vers_next;
> +			cond_resched();
>  		}
>  	}
>  	return 0;

Obligatory question: did you test this?

Brian

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] JFFS2: Prevent CPU starvation during garbage collection.
  2015-08-07 17:21 ` Brian Norris
@ 2015-08-09 22:24   ` Mark Tomlinson
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Tomlinson @ 2015-08-09 22:24 UTC (permalink / raw)
  To: Brian Norris; +Cc: linux-mtd@lists.infradead.org, David Woodhouse

I have tested that this does reduce latency for other processes. In our 
embedded system, one process tries to wake up every 1000ms using poll(). 
During JFFS2's period of scanning, it could take 2500ms before that 
process got the CPU. After this patch, the longest I ever saw was 
1050ms, which is much more acceptable to us.

The only question that remains is whether allowing a reschedule at this 
point is OK to do or not. My reasoning below says that it is, but I 
could be mistaken. I have not seen any bad behaviour while running with 
this patch.

On 08/08/2015 05:21 AM, Brian Norris wrote:
> + David
>
> I'm not maintaining JFFS2, but if it's exceedingly obvious (this patch
> might qualify), I might take patches.
>
> On Wed, Aug 05, 2015 at 04:40:30PM +1200, Mark Tomlinson wrote:
>> The JFFS2 garbage collection checks every file on the system for correct
>> checksums and cleaning up anything that it needs to. It sleeps for 50ms
>> between each file, but within each file it remains busy.
>>
>> As far as I can tell, there is no reason to not reschedule while checking a
>> file, by putting a cond_resched() inside jfffs2_build_inode_fragtree(). In
>> fact, jffs2_get_inode_nodes() will call cond_resched(), which is done
>> immediately before jffs2_build_inode_fragtree().
>>
>> With this extra cond_resched() between reading file blocks, there is a
>> dramatic improvement in latency for any processes which are running during
>> this initial garbage collection phase.
>>
>> Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
>> ---
>>   fs/jffs2/readinode.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
>> index 28e0aab..78c526a 100644
>> --- a/fs/jffs2/readinode.c
>> +++ b/fs/jffs2/readinode.c
>> @@ -536,6 +536,7 @@ static int jffs2_build_inode_fragtree(struct jffs2_sb_info *c,
>>   				jffs2_free_tmp_dnode_info(this);
>>   			}
>>   			this = vers_next;
>> +			cond_resched();
>>   		}
>>   	}
>>   	return 0;
> Obligatory question: did you test this?
>
> Brian

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-08-09 22:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-05  4:40 [PATCH] JFFS2: Prevent CPU starvation during garbage collection Mark Tomlinson
2015-08-07 17:21 ` Brian Norris
2015-08-09 22:24   ` Mark Tomlinson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.