[G Pad 8.3 Android Development] aicjofs:
It's possible the GPE has different headroom, we know there are slight differences between the 2 pads. It really seems LG is aware of it. From arch/arm/mach-msm/lge/awifi/board-awifi.c(check palman for you)

static struct msm_thermal_data msm_thermal_pdata = {
.sensor_id = 7,
[COLOR="Red"][B]#ifdef CONFIG_MACH_LGE[/B][/COLOR]
.poll_ms = 500,
.limit_temp_degC =[COLOR="red"][B] 93[/B][/COLOR],
[COLOR="RoyalBlue"][B]#else[/B][/COLOR]
.poll_ms = 250,
.limit_temp_degC =[B][COLOR="RoyalBlue"] 60,[/COLOR][/B]
#endif
.temp_hysteresis_degC = 5,
.freq_step = 1,
[COLOR="Red"][B]#if defined(CONFIG_MACH_APQ8064_AWIFI)[/B][/COLOR]
// It is cause of MPdecision problem. so, changed to Higher value than Thermal_deamon's setting
.core_limit_temp_degC = [B][COLOR="Red"]120,[/COLOR][/B]
[COLOR="RoyalBlue"][B]#else[/B][/COLOR]
.core_limit_temp_degC = [B][COLOR="RoyalBlue"]80,[/COLOR][/B]
#endif
.core_temp_hysteresis_degC = 10,

.core_control_mask = 0xe,
};

I assume this is the LG changes from a base 8064. Notice the IF/ELSE, LG has bumped up their stuff 30-40C

Here's what I said about it when I researched it. http://xdaforums.com/showpost.php?p=54482330&postcount=229

Take a look at the the thermald config file for the GPE. For the 500 it's at /system/etc/thermald-8064.conf Where you really run it to problems with thermald is that if you go over one of the limits it resets the freq table so you lose the overclock. You can edit the config or switch to open source thermal but at the end of the day you have to be pushing past 100C at 4 core 100% CPU load to get any meaningful overclock at that IMO is just not an option that I was willing to release for other peoples tablets. No matter what I found it's best to ditch thermald and mpdecision and go with open source versions. They just interfere too much with the overclock.

The one promising thing I found in regards to CPU overclocking was a turbo boost. I never quite got it how I wanted to but the premise is you can boost 1 or 2 cores to 2.0ghz and still stay under the thermal. So for single threaded apps you can see an improvement. Another not so "overclocking" improvement to play around with is the L2 cache

acpuclock-8064.c

{ 1026000, HFPLL, 1, 0x26 }, L2(5), 925000 }, <------- Change from 5 to 14
{ 1, { 1134000, HFPLL, 1, 0x2A }, L2(15), 937500 }, <-------Change all the 15's to 14's
{ 1, { 1242000, HFPLL, 1, 0x2E }, L2(15), 950000 },
{ 1, { 1350000, HFPLL, 1, 0x32 }, L2(15), 962500 },
{ 1, { 1458000, HFPLL, 1, 0x36 }, L2(15), 987500 },
{ 1, { 1566000, HFPLL, 1, 0x3A }, L2(15), 1012500 },
{ 1, { 1674000, HFPLL, 1, 0x3E }, L2(15), 1050000 },
{ 1, { 1728000, HFPLL, 1, 0x40 }, L2(15), 1075000 },
{ 0, { 0 } }

The idea being that the jump from 14 to 15 adds a latency penalty, so reducing the L2 bus freq is a benefit despite losing bus speed there isn't idle CPU cycles waiting because of the async operation. The second tweak is the changing the L2 bus speed at the 1026 level. Depending on governor the CPU spends a lot of time at this freq so the improved L2 bus speed makes an improvement.

The biggest bang for the buck is GPU overclocking. The thermal headroom is there, most chips can do 487 without issue, and the frame rate increase is obvious is demanding games, where all the CPU increases are mostly only noticeable in benchmarks.