# "git -gc" eats all of my I/O resources

## toralf

Today I run a "make" within the svn version of wireshark, in parallel a "emerge sync" and then I decided to make a "git pull" for the current vanilla kernel. The git command however decided to run a "git -gc" prior to the pull. (vanilla kernel 2.67.35.4, 2 GB RAM within my ThinkPad T400 running a straight x86 32bit Gentoo)

The result was that the first 2 commands were slowed down nearly to zero. I could however within KDE switch the Konsole windows and so on, however disk activity related actions weren't possible.

After half an hour "git -gc" was finished and all processes continued to work to their expected end.

Now I'm wonering why the git command could eat nearly all I/O related resources.

----------

## Hu

Running git gc is expected to produce quite a bit of I/O.  We would need to know what I/O scheduler and filesystems you use to know whether the extremely unfair I/O allocation is expected.  We will also need to examine the source for 2.67.35.4, once it comes out.  This could take a while however, as current indications are that we will remain with 2.6.x.y for quite some time.

----------

## toralf

 *Hu wrote:*   

> We will also need to examine the source for 2.67.35.4, once it comes out.

   :Embarassed: 

Well, with vanilla 2.6.35.4 it is reproducible too. Beside that I use this config values :

```
CONFIG_IOSCHED_NOOP=y

CONFIG_IOSCHED_CFQ=y

CONFIG_DEFAULT_IOSCHED="cfq"

CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y

CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

CONFIG_CPU_FREQ_GOV_POWERSAVE=m

CONFIG_CPU_FREQ_GOV_ONDEMAND=y

CONFIG_CPU_IDLE_GOV_LADDER=y

CONFIG_CPU_IDLE_GOV_MENU=y

```

at a ext3 file system :

```
Filesystem           1K-blocks      Used Available Use% Mounted on

/dev/sda7             39456264  25557488  11894500  69% /

```

The cpu governor might be interesting too b/c I run conky in the background which told me that for a certain amount of time the CPU went down from 2.401 GHz to 800 MHz although I'd expect a higher value.

----------

## Hu

The configuration you showed indicates that you use the ondemand governor by default, so the kernel should automatically run the CPU at the best frequency for the current workload.

Running an emerge --sync and a git gc in parallel on a single ext3 filesystem sounds unwise.  Syncing the tree can require a huge number of seeks and small writes, depending on how current your tree is before you start.  Collecting garbage files in a git repository requires scattered reads and grouped writes.  Combine all that on one filesystem and throw in the relatively simplistic block allocation of ext3 (as compared to ext4 with mballoc, delalloc, and extents), and you have a recipe for trouble.  I am a bit disappointed that it was so unfair (giving all the time to git gc at the expense of the sync), but that might be a function of git gc having a greater number of writes and therefore monopolizing the journal and/or key filesystem locks.

Your best bet is probably some combination of:Do not do that again.Move /usr/portage to a separate filesystem.  In particular, consider using something like squashfs so that you do not need a separate file on the main filesystem for each ebuild, patch, eclass, etc.Convert / to ext4.  This can be done without reformatting, though you will need to unmount it before converting.

----------

## toralf

In the meanwhile I suspect the cpu ondemand governor to be involved too b/c after I changed the make flag -j from 3 to 2 I didn't observed such things until now.

----------

