"e98f1b96" (history) in projects: dragonfly

Project(s)

Full Search
Definition
Symbol
File Path
History
Type

Searched hist:e98f1b96 (Results 1 – 6 of 6) sorted by relevance

/dragonfly/sys/vfs/hammer/
H A D	hammer_prune.c	e98f1b96 Fri Feb 19 18:41:22 GMT 2010 Matthew Dillon <dillon@apollo.backplane.com> HAMMER VFS - Reduce stalls during bulk file operations * Track modifying inode operations on a per-PID basis (loosely) and call hammer_inode_wait_reclaims() earlier for those pids. The algorithm selects a wait point based on the process's perceived contribution to the inode load. The greater the contribution, the more readily we stall the process in order to wait for related reclaims to process. Processes with lower loads have higher reclaim points and do not stall as readily as they did before. * Remove waitreclaims calls based on B-Tree scans. I'm not sure why I had this in there but it was creating an excessive number of unnecessary stalls, so if any problems crop up I'll have to find another way to deal with them. * These changes (particularly the first) should reduce unnecessary stalls for the programs not doing heavy inode operations. Hopefully that means rm -rf and tar extractions will not have as quite the detrimental effect on other processes as they did before.
H A D	hammer_transaction.c	e98f1b96 Fri Feb 19 18:41:22 GMT 2010 Matthew Dillon <dillon@apollo.backplane.com> HAMMER VFS - Reduce stalls during bulk file operations * Track modifying inode operations on a per-PID basis (loosely) and call hammer_inode_wait_reclaims() earlier for those pids. The algorithm selects a wait point based on the process's perceived contribution to the inode load. The greater the contribution, the more readily we stall the process in order to wait for related reclaims to process. Processes with lower loads have higher reclaim points and do not stall as readily as they did before. * Remove waitreclaims calls based on B-Tree scans. I'm not sure why I had this in there but it was creating an excessive number of unnecessary stalls, so if any problems crop up I'll have to find another way to deal with them. * These changes (particularly the first) should reduce unnecessary stalls for the programs not doing heavy inode operations. Hopefully that means rm -rf and tar extractions will not have as quite the detrimental effect on other processes as they did before.
H A D	hammer_object.c	e98f1b96 Fri Feb 19 18:41:22 GMT 2010 Matthew Dillon <dillon@apollo.backplane.com> HAMMER VFS - Reduce stalls during bulk file operations * Track modifying inode operations on a per-PID basis (loosely) and call hammer_inode_wait_reclaims() earlier for those pids. The algorithm selects a wait point based on the process's perceived contribution to the inode load. The greater the contribution, the more readily we stall the process in order to wait for related reclaims to process. Processes with lower loads have higher reclaim points and do not stall as readily as they did before. * Remove waitreclaims calls based on B-Tree scans. I'm not sure why I had this in there but it was creating an excessive number of unnecessary stalls, so if any problems crop up I'll have to find another way to deal with them. * These changes (particularly the first) should reduce unnecessary stalls for the programs not doing heavy inode operations. Hopefully that means rm -rf and tar extractions will not have as quite the detrimental effect on other processes as they did before.
H A D	hammer_inode.c	e98f1b96 Fri Feb 19 18:41:22 GMT 2010 Matthew Dillon <dillon@apollo.backplane.com> HAMMER VFS - Reduce stalls during bulk file operations * Track modifying inode operations on a per-PID basis (loosely) and call hammer_inode_wait_reclaims() earlier for those pids. The algorithm selects a wait point based on the process's perceived contribution to the inode load. The greater the contribution, the more readily we stall the process in order to wait for related reclaims to process. Processes with lower loads have higher reclaim points and do not stall as readily as they did before. * Remove waitreclaims calls based on B-Tree scans. I'm not sure why I had this in there but it was creating an excessive number of unnecessary stalls, so if any problems crop up I'll have to find another way to deal with them. * These changes (particularly the first) should reduce unnecessary stalls for the programs not doing heavy inode operations. Hopefully that means rm -rf and tar extractions will not have as quite the detrimental effect on other processes as they did before.
H A D	hammer_vnops.c	e98f1b96 Fri Feb 19 18:41:22 GMT 2010 Matthew Dillon <dillon@apollo.backplane.com> HAMMER VFS - Reduce stalls during bulk file operations * Track modifying inode operations on a per-PID basis (loosely) and call hammer_inode_wait_reclaims() earlier for those pids. The algorithm selects a wait point based on the process's perceived contribution to the inode load. The greater the contribution, the more readily we stall the process in order to wait for related reclaims to process. Processes with lower loads have higher reclaim points and do not stall as readily as they did before. * Remove waitreclaims calls based on B-Tree scans. I'm not sure why I had this in there but it was creating an excessive number of unnecessary stalls, so if any problems crop up I'll have to find another way to deal with them. * These changes (particularly the first) should reduce unnecessary stalls for the programs not doing heavy inode operations. Hopefully that means rm -rf and tar extractions will not have as quite the detrimental effect on other processes as they did before.
H A D	hammer.h	e98f1b96 Fri Feb 19 18:41:22 GMT 2010 Matthew Dillon <dillon@apollo.backplane.com> HAMMER VFS - Reduce stalls during bulk file operations * Track modifying inode operations on a per-PID basis (loosely) and call hammer_inode_wait_reclaims() earlier for those pids. The algorithm selects a wait point based on the process's perceived contribution to the inode load. The greater the contribution, the more readily we stall the process in order to wait for related reclaims to process. Processes with lower loads have higher reclaim points and do not stall as readily as they did before. * Remove waitreclaims calls based on B-Tree scans. I'm not sure why I had this in there but it was creating an excessive number of unnecessary stalls, so if any problems crop up I'll have to find another way to deal with them. * These changes (particularly the first) should reduce unnecessary stalls for the programs not doing heavy inode operations. Hopefully that means rm -rf and tar extractions will not have as quite the detrimental effect on other processes as they did before.