AMD Pstate Fixes And Enhancements

As there are some AMD processors which only support CPPC V2 firmware and BIOS implementation, the amd_pstate driver will be failed to load when system booting with below kernel warning message:

[    0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled

To make the amd_pstate driver can be loaded on those TR40 processors, it needs to match x86_model from 0x30 to 0x7F for family 17H. With the change, the system can load amd_pstate driver as expected.

Reviewed-by Mario Limonciello <[email protected]>

Reported-by Gino Badouri <[email protected]>

Closes https://bugzilla.kernel.org/show_bug.cgi?id=218171

Fixes fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory")

Signed-off-by Perry Yuan <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kernel/acpi/cppc.c +0 -0

index 8d8752b44f11..ff8f25faca3d 100644

Hello Perry,

Quoted 24 lines · Perry Yuan

As there are some AMD processors which only support CPPC V2 firmware and BIOS implementation, the amd_pstate driver will be failed to load when system booting with below kernel warning message:

[    0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled

To make the amd_pstate driver can be loaded on those TR40 processors, it needs to match x86_model from 0x30 to 0x7F for family 17H. With the change, the system can load amd_pstate driver as expected.

Reviewed-by Mario Limonciello <[email protected]>

Reported-by Gino Badouri <[email protected]>

Closes https://bugzilla.kernel.org/show_bug.cgi?id=218171

Fixes fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory")

Signed-off-by Perry Yuan <[email protected]>

---
 arch/x86/kernel/acpi/cppc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kernel/acpi/cppc.c +0 -0

index 8d8752b44f11..ff8f25faca3d 100644

arch/x86/kernel/acpi/cppc.c bool cpc_supported_by_cpu(void) · line 23

Quoted 5 lines

arch/x86/kernel/acpi/cppc.c +1 -1

@@ -20,7 +20,7 @@ bool cpc_supported_by_cpu(void)
                  (boot_cpu_data.x86_model >= 0x20 && boot_cpu_data.x86_model <= 0x2f)))
                      return true;
              else if (boot_cpu_data.x86 == 0x17 &&
-                      boot_cpu_data.x86_model >= 0x70 && boot_cpu_data.x86_model <= 0x7f)
+                      boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x7f)

This looks ok to me.

Reviewed-by Gautham R. Shenoy <[email protected]>

Address an untested error where the nominal_freq was returned in KHz instead of the correct MHz units, this oversight led to a wrong nominal_freq set and resued, it will cause the max frequency of core to be initialized with a wrong frequency value.

Cc [email protected]

Fixes ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")

Reviewed-by Mario Limonciello <[email protected]>

Signed-off-by Perry Yuan <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/cpufreq/amd-pstate.c +1 -2

index 08e112444c27..ac7faa98a450 100644
@@ -640,8 +640,7 @@ static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
 	if (ret)
 		return ret;
 
-	/* Switch to khz */
-	return cppc_perf.nominal_freq * 1000;
+	return cppc_perf.nominal_freq;
 }
 
 static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)

Signature · 1 line

2.34.1

Quoted 4 lines · Perry Yuan

Address an untested error where the nominal_freq was returned in KHz instead of the correct MHz units, this oversight led to a wrong nominal_freq set and resued, it will cause the max frequency of core to be initialized with a wrong frequency value.

The _CPC object on my Zen2 EPYC server which has CPPC v3, I see :

            0x00000190,			//LowestFrequency 
            0x000007D0			//NominalFrequency
        })
    }

where 0x7D0 is 2000 Mhz. Thus the value returend by cppc_perf.nominal_freq is in Mhz.

In this patch, we are changing making amd_get_nominal_freq() return 2000 (Mhz) instead of 2000000 (Khz) as it was doing previously.

amd_get_min_freq(), amd_get_max_freq(), amd_get_lowest_nonlinear_perf() -all these functions return the frequency in Khz units.

These functions are used the initialize the value of cpudata->max_freq, cpu_data->min_freq, .... all of which are in Khz units.

In, amd_pstate_set_boost(), we have:

	if (state)
		policy->cpuinfo.max_freq = cpudata->max_freq;  <---- In Khz
	else
		policy->cpuinfo.max_freq = cpudata->nominal_freq; <--- Now in Mhz

Since policy->cpuinfo.max_freq is expected to be in Khz, isn't this patch introducing an error ? Or perhaps this patch series is based on another patchset ?

--
Thanks and Regards
gautham.

Quoted 26 lines

Cc [email protected]

Fixes ec437d71db7 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors")

Reviewed-by Mario Limonciello <[email protected]>

Signed-off-by Perry Yuan <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/cpufreq/amd-pstate.c +1 -2

index 08e112444c27..ac7faa98a450 100644
@@ -640,8 +640,7 @@ static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
 	if (ret)
 		return ret;
 
-	/* Switch to khz */
-	return cppc_perf.nominal_freq * 1000;
+	return cppc_perf.nominal_freq;
 }
 
 static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)

Signature · 1 line

2.34.1

Optimizes the process of retrieving the nominal frequency by utilizing 'cpudata->nominal_freq' instead of repeatedly accessing the cppc_acpi interface.

To enhance efficiency and reduce the CPU load, shifted to using 'cpudata->nominal_freq'. It allows for the nominal frequency to be accessed directly from the cached data in 'cpudata' of each CPU.
It will also slightly reduce the frequency change latency while using pstate driver passive mode.

Reviewed-by Mario Limonciello <[email protected]>

Signed-off-by Perry Yuan <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

drivers/cpufreq/amd-pstate.c +0 -0

index ac7faa98a450..ea8681ea3bad 100644

drivers/cpufreq/amd-pstate.c +1 -1

 	nominal_perf = READ_ONCE(cpudata->nominal_perf);
 	max_perf = READ_ONCE(cpudata->highest_perf);
 

@@ -654,7 +654,7 @@ static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)
 	if (ret)
 		return ret;
 
-	nominal_freq = cppc_perf.nominal_freq;
+	nominal_freq = READ_ONCE(cpudata->nominal_freq);
 	nominal_perf = READ_ONCE(cpudata->nominal_perf);
 
 	lowest_nonlinear_perf = cppc_perf.lowest_nonlinear_perf;

@@ -848,13 +848,14 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
 		goto free_cpudata1;
 
 	min_freq = amd_get_min_freq(cpudata);

drivers/cpufreq/amd-pstate.c +2 -1

+		dev_err(dev, "min_freq(%d) or max_freq(%d) or nominal_freq(%d) is incorrect\n",
+			min_freq, max_freq, nominal_freq);
 		ret = -EINVAL;
 		goto free_cpudata1;
 	}

@@ -893,7 +894,6 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
 	cpudata->min_freq = min_freq;
 	cpudata->max_limit_freq = max_freq;
 	cpudata->min_limit_freq = min_freq;
-	cpudata->nominal_freq = nominal_freq;
 	cpudata->lowest_nonlinear_freq = lowest_nonlinear_freq;
 
 	policy->driver_data = cpudata;

@@ -1310,12 +1310,13 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
 		goto free_cpudata1;
 

to be more clear what is wrong with CPPC when pstate driver failed to load which has dependency on the CPPC capabilities.

Add one more debug message to notify user if CPPC is not supported by the CPU, then it will be easy to find out what need to fix for pstate driver loading issue.

[    0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled

Above message is not clear enough to verify whether CPPC is not supported.

Reviewed-by Mario Limonciello <[email protected]>

Signed-off-by Perry Yuan <[email protected]>

---
 drivers/acpi/cppc_acpi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/acpi/cppc_acpi.c +3 -1

index a50e70abdf19..e23a84f4a50a 100644
@@ -679,8 +679,10 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
 
 	if (!osc_sb_cppc2_support_acked) {
 		pr_debug("CPPC v2 _OSC not acked\n");
-		if (!cpc_supported_by_cpu())
+		if (!cpc_supported_by_cpu()) {
+			pr_debug("CPPC is not supported by the CPU\n");
 			return -ENODEV;
+		}
 	}
 
 	/* Parse the ACPI _CPC table for this CPU. */

Signature · 1 line

2.34.1

Add quirks table to get CPPC capabilities issue fixed by providing correct perf or frequency values while driver loading.

If CPPC capabilities are not defined in the ACPI tables or wrongly defined by platform firmware, it needs to use quick to get those issues fixed with correct workaround values to make pstate driver can be loaded even though there are CPPC capabilities errors.

The workaround will match the broken BIOS which lack of CPPC capabilities nominal_freq and lowest_freq definition in the ACPI table.

$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq
0
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq
0

Reviewed-by Mario Limonciello <[email protected]>

Signed-off-by Perry Yuan <[email protected]>

---
 drivers/cpufreq/amd-pstate.c | 57 ++++++++++++++++++++++++++++++++++--
 include/linux/amd-pstate.h   |  6 ++++
 2 files changed, 61 insertions(+), 2 deletions(-)

drivers/cpufreq/amd-pstate.c +55 -2

index 77effc3caf6c..ff4727c22dce 100644
@@ -67,6 +67,7 @@ static struct cpufreq_driver amd_pstate_epp_driver;
 static int cppc_state = AMD_PSTATE_UNDEFINED;
 static bool cppc_enabled;
 static bool amd_pstate_prefcore = true;
+static struct quirk_entry *quirks;
 
 /*
  * AMD Energy Preference Performance (EPP)

@@ -111,6 +112,41 @@ static unsigned int epp_values[] = {
 
 typedef int (*cppc_mode_transition_fn)(int);
 
+static struct quirk_entry quirk_amd_7k62 = {
+	.nominal_freq = 2600,
+	.lowest_freq = 550,
+};
+
+static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
+{
+	/**
+	 * match the broken bios for family 17h processor support CPPC V2
+	 * broken BIOS lack of nominal_freq and lowest_freq capabilities
+	 * definition in ACPI tables
+	 */
+	if (boot_cpu_has(X86_FEATURE_ZEN2)) {
+		quirks = dmi->driver_data;
+		pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
+		return 1;
+	}
+
+	return 0;
+}
+
+static const struct dmi_system_id amd_pstate_quirks_table[] __initconst = {
+	{
+		.callback = dmi_matched_7k62_bios_bug,
+		.ident = "AMD EPYC 7K62",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VERSION, "5.14"),
+			DMI_MATCH(DMI_BIOS_RELEASE, "12/12/2019"),
+		},
+		.driver_data = &quirk_amd_7k62,
+	},
+	{}
+};
+MODULE_DEVICE_TABLE(dmi, amd_pstate_quirks_table);
+
 static inline int get_mode_idx_from_str(const char *str, size_t size)
 {
 	int i;

@@ -600,13 +636,19 @@ static void amd_pstate_adjust_perf(unsigned int cpu,
 static int amd_get_min_freq(struct amd_cpudata *cpudata)
 {
 	struct cppc_perf_caps cppc_perf;
+	u32 lowest_freq;
 
 	int ret = cppc_get_perf_caps(cpudata->cpu, &cppc_perf);
 	if (ret)
 		return ret;
 
+	if (quirks && quirks->lowest_freq)
+		lowest_freq = quirks->lowest_freq;
+	else
+		lowest_freq = cppc_perf.lowest_freq;
+
 	/* Switch to khz */
-	return cppc_perf.lowest_freq * 1000;
+	return lowest_freq * 1000;
 }
 
 static int amd_get_max_freq(struct amd_cpudata *cpudata)

@@ -635,12 +677,18 @@ static int amd_get_max_freq(struct amd_cpudata *cpudata)
 static int amd_get_nominal_freq(struct amd_cpudata *cpudata)
 {
 	struct cppc_perf_caps cppc_perf;
+	u32 nominal_freq;
 
 	int ret = cppc_get_perf_caps(cpudata->cpu, &cppc_perf);
 	if (ret)
 		return ret;
 
-	return cppc_perf.nominal_freq;
+	if (quirks && quirks->nominal_freq)
+		nominal_freq = quirks->nominal_freq;
+	else
+		nominal_freq = cppc_perf.nominal_freq;
+
+	return nominal_freq;
 }
 
 static int amd_get_lowest_nonlinear_freq(struct amd_cpudata *cpudata)

@@ -1672,6 +1720,11 @@ static int __init amd_pstate_init(void)
 	if (cpufreq_get_current_driver())
 		return -EEXIST;
 
+	quirks = NULL;
+
+	/* check if this machine need CPPC quirks */
+	dmi_check_system(amd_pstate_quirks_table);
+
 	switch (cppc_state) {
 	case AMD_PSTATE_UNDEFINED:
 		/* Disable on the following configs by default:

include/linux/amd-pstate.h +6 -0

index d21838835abd..7b2cbb892fd9 100644
@@ -124,4 +124,10 @@ static const char * const amd_pstate_mode_string[] = {
 	[AMD_PSTATE_GUIDED]      = "guided",
 	NULL,
 };
+
+struct quirk_entry {
+	u32 nominal_freq;
+	u32 lowest_freq;
+};
+
 #endif /* _LINUX_AMD_PSTATE_H */

Signature · 1 line

2.34.1

The patch series adds some fixes and enhancements to the AMD pstate driver.

-----Original Message-----
From: Borislav Petkov <[email protected]>
Sent: Thursday, February 8, 2024 5:21 AM
To: Yuan, Perry <[email protected]>
Cc: [email protected]; Limonciello, Mario <[email protected]>; [email protected]; Huang, Ray <[email protected]>; Shenoy, Gautham Ranjal <[email protected]>; Deucher, Alexander <[email protected]>; Huang, Shimmer <[email protected]>; Du, Xiaojian <[email protected]>; Meng, Li (Jassmine) <[email protected]>; [email protected]; linux- [email protected]
Subject: Re: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements

Quoted 2 lines · Perry Yuan

The patch series adds some fixes and enhancements to the AMD pstate driver.

Is there any chance you could stop spamming people with your patchset?

102625 O T Feb 02 Perry Yuan ( : 12K|) [PATCH v2 0/6] AMD Pstate
Fixes And Enhancements
104232 O T Feb 04 Perry Yuan ( : 12K|) [PATCH v3 0/6] AMD Pstate
Fixes And Enhancements
106714 O T Feb 06 Perry Yuan ( : 12K|) [PATCH v4 0/6] AMD Pstate
Fixes And Enhancements
107828 O T Feb 07 Perry Yuan ( : 13K|) [PATCH v5 0/6] AMD Pstate
Fixes And Enhancements
108745 N T Feb 08 Perry Yuan ( : 13K|) [PATCH v6 0/6] AMD Pstate
Fixes And Enhancements

You should send stuff once a week tops, not every other day.

While waiting your can read about it in Documentation/process/submitting- patches.rst

"Don't get discouraged - or impatient
------------------------------------

After you have submitted your change, be patient and wait. Reviewers are busy people and may not get to your patch right away.

Once upon a time, patches used to disappear into the void without comment, but the development process works more smoothly than that now. You should receive comments within a few weeks (typically 2-3); if that does not happen, make sure that you have sent your patches to the right place. Wait for a minimum of one week before resubmitting or pinging reviewers
- possibly longer during busy times like merge windows.

It's also ok to resend the patch or the patch series after a couple of weeks with the word "RESEND" added to the subject line::

[PATCH Vx RESEND] sub/sys: Condensed patch summary

Don't add "RESEND" when you are submitting a modified version of your patch or patch series - "RESEND" only applies to resubmission of a patch or patch series which have not been modified in any way from the previous submission."

Thx.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Why?

In this case, there have been a number of review comments which have been addressed in the new revisions of the patch set. Why delay the new revisions?

You'll ultimately get the same amount of email just with a much longer latency.

-----Original Message-----
From: Borislav Petkov <[email protected]>
Sent: Friday, February 9, 2024 10:51 AM
To: Deucher, Alexander <[email protected]>
Cc: Yuan, Perry <[email protected]>; [email protected]; Limonciello, Mario <[email protected]>; [email protected]; Huang, Ray <[email protected]>; Shenoy, Gautham Ranjal <[email protected]>; Huang, Shimmer <[email protected]>; Du, Xiaojian <[email protected]>; Meng, Li (Jassmine) <[email protected]>; [email protected]; linux- [email protected]
Subject: Re: [PATCH v6 0/6] AMD Pstate Fixes And Enhancements

Quoted 1 line · Alexander

Why?

Because we have those rules, you know. You should send about once a week, unless you've reworked your set fundamentally.

Otherwise maintainers mailboxes would be a serious mess. Not that they're already such now...

Quoted 3 lines

In this case, there have been a number of review comments which have been addressed in the new revisions of the patch set. Why delay the new revisions?

See above.

And see below for the "whopping" differences between the last two.

Quoted 2 lines

You'll ultimately get the same amount of email just with a much longer latency.

No, you'll have a lot less email. You send the set, sit tight and collect review feedback, work it in and send again after a week or so.

diff v5..v6 - definitely not resend one day later just to pick up tags.
-----------
--- v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx

      2024-02-09 16:43:29.487104935 +0100
+++ v6_20240208_perry_yuan_amd_pstate_fixes_and_enhancements.mbx
      2024-02-09 16:42:55.671303380 +0100

v6_20240208_perry_yuan_amd_pstate_fixes_and_enhancements.mbx renamed from v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx +1 -0

@@ -23,6 +23,7 @@ Reported-by: Gino Badouri <badouri.g@gma
 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218171
 Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with
 shared memory")
 Signed-off-by: Perry Yuan <[email protected]>
+Reviewed-by: Gautham R. Shenoy <[email protected]>
 ---
  arch/x86/kernel/acpi/cppc.c | 2 +-

  1 file changed, 1 insertion(+), 1 deletion(-) @@ -293,6 +294,7 @@ Above

message is not clear enough to ver

Reviewed-by Mario Limonciello <[email protected]>

Signed-off-by Perry Yuan <[email protected]>

+Reviewed-by: Gautham R. Shenoy <[email protected]>
---

  drivers/acpi/cppc_acpi.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-) @@ -342,8 +344,9 @@ $ cat
/sys/devices/system/cpu/cpu0/acpi_
 $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq
 0

v6_20240208_perry_yuan_amd_pstate_fixes_and_enhancements.mbx renamed from v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx +3 -1

-Signed-off-by: Perry Yuan <[email protected]>
 Reviewed-by: Mario Limonciello <[email protected]>
+Signed-off-by: Perry Yuan <[email protected]>
+Reviewed-by: Gautham R. Shenoy <[email protected]>
 ---
  drivers/cpufreq/amd-pstate.c | 57
++++++++++++++++++++++++++++++++++--
  include/linux/amd-pstate.h   |  6 ++++

diff v4..v5 - *definitely* *not* warranting a new resend on the next day!
-----------
--- v4_20240206_perry_yuan_amd_pstate_fixes_and_enhancements.mbx

      2024-02-09 16:43:53.922961536 +0100
+++ v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx
      2024-02-09 16:43:29.487104935 +0100

v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx renamed from v4_20240206_perry_yuan_amd_pstate_fixes_and_enhancements.mbx +5 -2

@@ -343,13 +343,14 @@ $ cat /sys/devices/system/cpu/cpu0/acpi_
 0
 
 Signed-off-by: Perry Yuan <[email protected]>
+Reviewed-by: Mario Limonciello <[email protected]>
 ---
- drivers/cpufreq/amd-pstate.c | 59
++++++++++++++++++++++++++++++++++--
+ drivers/cpufreq/amd-pstate.c | 57
++++++++++++++++++++++++++++++++++--
  include/linux/amd-pstate.h   |  6 ++++
- 2 files changed, 63 insertions(+), 2 deletions(-)
+ 2 files changed, 61 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c -

index 77effc3caf6c..874d8b663790 100644

v5_20240207_perry_yuan_amd_pstate_fixes_and_enhancements.mbx renamed from v4_20240206_perry_yuan_amd_pstate_fixes_and_enhancements.mbx +3 -2

+index 77effc3caf6c..ff4727c22dce 100644
 --- a/drivers/cpufreq/amd-pstate.c
 +++ b/drivers/cpufreq/amd-pstate.c
 @@ -67,6 +67,7 @@ static struct cpufreq_driver amd_pstate_epp_driver;

@@ -372,18 +373,16 @@ index 77effc3caf6c..874d8b663790 100644
+static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id
 *dmi)  +{
 +    /**
-+     * match the broken bios for family 17h, model 31h processor
++     * match the broken bios for family 17h processor support CPPC V2
 +     * broken BIOS lack of nominal_freq and lowest_freq capabilities
 +     * definition in ACPI tables
 +     */
-+    if (boot_cpu_data.x86 == 0x17 && boot_cpu_data.x86_model ==

0x31 &&
-+ boot_cpu_has(X86_FEATURE_ZEN2)) {
++ if (boot_cpu_has(X86_FEATURE_ZEN2)) {

 +            quirks = dmi->driver_data;
-+            pr_info("hardware type %s found\n", dmi->ident);
++            pr_info("Overriding nominal and lowest frequencies for

%s\n",
++dmi->ident);
+ return 1;
+ }
+
-+
+ return 0;
+}
+

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

My reading of the rules is that you should wait before resending or pinging if you have not received feedback.

If you are actively receiving feedback, to me, it makes sense to rapidly iterate. If a patch is reviewed and comments are addressed, it can land rather than waiting an extra week or two.

It also adds extra latency. With my maintainer hat on, I'd like to have new revisions rapidly. I guess it comes down to personal preference, but I don't do well with task switching.

When a patch set is fresh in my mind, I'd rather see it finished off and committed sooner rather than lingering and then a week or two later, I'd need to page the whole discussion back into my head to make sure everything was addressed and all the tags were collected.