[PATCH v2 net] be2net: fix link failure after ethtool offline test
Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.
Changes in v2:
- added fixes header
Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self tests.")
Signed-off-by: Petr Oros
---
.../net/ethernet/emulex/benet/be_ethtool.c| 28 +++
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c
b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 8a6785173228f3..492f8769ac12c2 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -891,7 +891,7 @@ static void be_self_test(struct net_device *netdev, struct
ethtool_test *test,
u64 *data)
{
struct be_adapter *adapter = netdev_priv(netdev);
- int status;
+ int status, cnt;
u8 link_status = 0;
if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
@@ -902,6 +902,9 @@ static void be_self_test(struct net_device *netdev, struct
ethtool_test *test,
memset(data, 0, sizeof(u64) * ETHTOOL_TESTS_NUM);
+ /* check link status before offline tests */
+ link_status = netif_carrier_ok(netdev);
+
if (test->flags & ETH_TEST_FL_OFFLINE) {
if (be_loopback_test(adapter, BE_MAC_LOOPBACK, [0]) != 0)
test->flags |= ETH_TEST_FL_FAILED;
@@ -922,13 +925,26 @@ static void be_self_test(struct net_device *netdev,
struct ethtool_test *test,
test->flags |= ETH_TEST_FL_FAILED;
}
- status = be_cmd_link_status_query(adapter, NULL, _status, 0);
- if (status) {
- test->flags |= ETH_TEST_FL_FAILED;
- data[4] = -1;
- } else if (!link_status) {
+ /* link status was down prior to test */
+ if (!link_status) {
test->flags |= ETH_TEST_FL_FAILED;
data[4] = 1;
+ return;
+ }
+
+ for (cnt = 10; cnt; cnt--) {
+ status = be_cmd_link_status_query(adapter, NULL, _status,
+ 0);
+ if (status) {
+ test->flags |= ETH_TEST_FL_FAILED;
+ data[4] = -1;
+ break;
+ }
+
+ if (link_status)
+ break;
+
+ msleep_interruptible(500);
}
}
--
2.21.0
[PATCH net] be2net: fix link failure after ethtool offline test
Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.
Signed-off-by: Petr Oros
---
.../net/ethernet/emulex/benet/be_ethtool.c| 28 +++
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c
b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 8a6785173228f3..492f8769ac12c2 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -891,7 +891,7 @@ static void be_self_test(struct net_device *netdev, struct
ethtool_test *test,
u64 *data)
{
struct be_adapter *adapter = netdev_priv(netdev);
- int status;
+ int status, cnt;
u8 link_status = 0;
if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
@@ -902,6 +902,9 @@ static void be_self_test(struct net_device *netdev, struct
ethtool_test *test,
memset(data, 0, sizeof(u64) * ETHTOOL_TESTS_NUM);
+ /* check link status before offline tests */
+ link_status = netif_carrier_ok(netdev);
+
if (test->flags & ETH_TEST_FL_OFFLINE) {
if (be_loopback_test(adapter, BE_MAC_LOOPBACK, [0]) != 0)
test->flags |= ETH_TEST_FL_FAILED;
@@ -922,13 +925,26 @@ static void be_self_test(struct net_device *netdev,
struct ethtool_test *test,
test->flags |= ETH_TEST_FL_FAILED;
}
- status = be_cmd_link_status_query(adapter, NULL, _status, 0);
- if (status) {
- test->flags |= ETH_TEST_FL_FAILED;
- data[4] = -1;
- } else if (!link_status) {
+ /* link status was down prior to test */
+ if (!link_status) {
test->flags |= ETH_TEST_FL_FAILED;
data[4] = 1;
+ return;
+ }
+
+ for (cnt = 10; cnt; cnt--) {
+ status = be_cmd_link_status_query(adapter, NULL, _status,
+ 0);
+ if (status) {
+ test->flags |= ETH_TEST_FL_FAILED;
+ data[4] = -1;
+ break;
+ }
+
+ if (link_status)
+ break;
+
+ msleep_interruptible(500);
}
}
--
2.21.0
Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update
Borislav Petkov píše v Pá 26. 01. 2018 v 15:49 +0100:
> On Fri, Jan 26, 2018 at 02:50:00PM +0100, Petr Oros wrote:
> > But what in production? Edit boot params, restart server, grep
> > /proc/cpuinfo and
> > restart again? Why i can not read it just from dmesg?
>
> Because you don't need the previous revision.
>
> You only *happen* to need it now but that is being addressed too with
> the blacklisting. And when you have broken microcode, it will say:
>
> + pr_warn("Intel Spectre v2 broken microcode detected;
> disabling SPEC_CTRL\n");
>
> and if you have microcode which doesn't have IBRS, there won't be
> "spec_ctrl" in /proc/cpuinfo.
>
> I don't want people to start paying attention to microcode
> revision numbers with the gazillion different revisions and
> family/model/steppings out there and the crazy confusion that will ensue
> from this.
>
We talk about dmesg log, it is place for diagnostic messages.
I think, people expected gazillion numbers here.
I adding only one number (microcode version) into log and only if patch is
applied. This is good also for future bugs, and for example for tools like
sosreport.
It is really better to have microcode version ready and not try find it and try
to collect after problem...
Btw: with hot microcode patch is possible to get previous version from dmesg
[0.680519] microcode: sig=0x306c3, pf=0x10, revision=0x23
Only with early it is not possible.
Thanks,
-Petr
Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update
Borislav Petkov píše v Pá 26. 01. 2018 v 15:49 +0100:
> On Fri, Jan 26, 2018 at 02:50:00PM +0100, Petr Oros wrote:
> > But what in production? Edit boot params, restart server, grep
> > /proc/cpuinfo and
> > restart again? Why i can not read it just from dmesg?
>
> Because you don't need the previous revision.
>
> You only *happen* to need it now but that is being addressed too with
> the blacklisting. And when you have broken microcode, it will say:
>
> + pr_warn("Intel Spectre v2 broken microcode detected;
> disabling SPEC_CTRL\n");
>
> and if you have microcode which doesn't have IBRS, there won't be
> "spec_ctrl" in /proc/cpuinfo.
>
> I don't want people to start paying attention to microcode
> revision numbers with the gazillion different revisions and
> family/model/steppings out there and the crazy confusion that will ensue
> from this.
>
We talk about dmesg log, it is place for diagnostic messages.
I think, people expected gazillion numbers here.
I adding only one number (microcode version) into log and only if patch is
applied. This is good also for future bugs, and for example for tools like
sosreport.
It is really better to have microcode version ready and not try find it and try
to collect after problem...
Btw: with hot microcode patch is possible to get previous version from dmesg
[0.680519] microcode: sig=0x306c3, pf=0x10, revision=0x23
Only with early it is not possible.
Thanks,
-Petr
Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update
Borislav Petkov píše v Pá 26. 01. 2018 v 12:58 +0100: > On Fri, Jan 26, 2018 at 12:45:35PM +0100, Petr Oros wrote: > > During time of facing the Spectre vulnerability and the requirement of > > handling > > different microcode updates, it has shown, that it would be useful to have > > additional information which microcode version was in BIOS, if the > > early-update > > routine will apply an update. > > Dmesg tells you if the update was applied or not. > > And if you really wanna know the old microcode revision, you can boot > with "dis_ucode_ldr" and do "grep microcode /proc/cpuinfo". > Ohh, yes, it is easy and fast. Mainly in time when new microcodes are released frequently and microcode can be early updated from initrd too. But what in production? Edit boot params, restart server, grep /proc/cpuinfo and restart again? Why i can not read it just from dmesg? Thanks, -Petr
Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update
Borislav Petkov píše v Pá 26. 01. 2018 v 12:58 +0100: > On Fri, Jan 26, 2018 at 12:45:35PM +0100, Petr Oros wrote: > > During time of facing the Spectre vulnerability and the requirement of > > handling > > different microcode updates, it has shown, that it would be useful to have > > additional information which microcode version was in BIOS, if the > > early-update > > routine will apply an update. > > Dmesg tells you if the update was applied or not. > > And if you really wanna know the old microcode revision, you can boot > with "dis_ucode_ldr" and do "grep microcode /proc/cpuinfo". > Ohh, yes, it is easy and fast. Mainly in time when new microcodes are released frequently and microcode can be early updated from initrd too. But what in production? Edit boot params, restart server, grep /proc/cpuinfo and restart again? Why i can not read it just from dmesg? Thanks, -Petr
Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update
Borislav Petkov píše v Pá 26. 01. 2018 v 11:41 +0100: > On Fri, Jan 26, 2018 at 11:34:50AM +0100, Petr Oros wrote: > > When kernel do early microcode update, code printing only > > new microcode version. But in this case we no have chance > > to check which version was in cpu from BIOS vendor. > > And we need that because? > During time of facing the Spectre vulnerability and the requirement of handling different microcode updates, it has shown, that it would be useful to have additional information which microcode version was in BIOS, if the early-update routine will apply an update.
Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update
Borislav Petkov píše v Pá 26. 01. 2018 v 11:41 +0100: > On Fri, Jan 26, 2018 at 11:34:50AM +0100, Petr Oros wrote: > > When kernel do early microcode update, code printing only > > new microcode version. But in this case we no have chance > > to check which version was in cpu from BIOS vendor. > > And we need that because? > During time of facing the Spectre vulnerability and the requirement of handling different microcode updates, it has shown, that it would be useful to have additional information which microcode version was in BIOS, if the early-update routine will apply an update.
[PATCH] x86/microcode/intel: print previous microcode revision during early update
When kernel do early microcode update, code printing only
new microcode version. But in this case we no have chance
to check which version was in cpu from BIOS vendor.
Patch add this info into output message.
Signed-off-by: Petr Oros <po...@redhat.com>
---
arch/x86/kernel/cpu/microcode/intel.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index d9e460fc7a3b..78330d29cd4c 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -515,9 +515,11 @@ static bool load_builtin_intel_microcode(struct cpio_data
*cp)
* Print ucode update info.
*/
static void
-print_ucode_info(struct ucode_cpu_info *uci, unsigned int date)
+print_ucode_info(struct ucode_cpu_info *uci, unsigned int date,
+ unsigned int prev_rev)
{
- pr_info_once("microcode updated early to revision 0x%x, date =
%04x-%02x-%02x\n",
+ pr_info_once("microcode updated early from revision 0x%x to 0x%x, date
= %04x-%02x-%02x\n",
+prev_rev,
uci->cpu_sig.rev,
date & 0x,
date >> 24,
@@ -528,6 +530,7 @@ print_ucode_info(struct ucode_cpu_info *uci, unsigned int
date)
static int delay_ucode_info;
static int current_mc_date;
+static int prev_revision;
/*
* Print early updated ucode info after printk works. This is delayed info
dump.
@@ -538,7 +541,7 @@ void show_ucode_info_early(void)
if (delay_ucode_info) {
collect_cpu_info_early();
- print_ucode_info(, current_mc_date);
+ print_ucode_info(, current_mc_date, prev_revision);
delay_ucode_info = 0;
}
}
@@ -547,11 +550,12 @@ void show_ucode_info_early(void)
* At this point, we can not call printk() yet. Delay printing microcode info
in
* show_ucode_info_early() until printk() works.
*/
-static void print_ucode(struct ucode_cpu_info *uci)
+static void print_ucode(struct ucode_cpu_info *uci, unsigned int prev_rev)
{
struct microcode_intel *mc;
int *delay_ucode_info_p;
int *current_mc_date_p;
+ int *prev_revision_p;
mc = uci->mc;
if (!mc)
@@ -559,13 +563,16 @@ static void print_ucode(struct ucode_cpu_info *uci)
delay_ucode_info_p = (int *)__pa_nodebug(_ucode_info);
current_mc_date_p = (int *)__pa_nodebug(_mc_date);
+ prev_revision_p = (int *)__pa_nodebug(_revision);
*delay_ucode_info_p = 1;
*current_mc_date_p = mc->hdr.date;
+ *prev_revision_p = prev_rev;
}
#else
-static inline void print_ucode(struct ucode_cpu_info *uci)
+static inline void print_ucode(struct ucode_cpu_info *uci,
+ unsigned int prev_rev)
{
struct microcode_intel *mc;
@@ -573,19 +580,21 @@ static inline void print_ucode(struct ucode_cpu_info *uci)
if (!mc)
return;
- print_ucode_info(uci, mc->hdr.date);
+ print_ucode_info(uci, mc->hdr.date, prev_rev);
}
#endif
static int apply_microcode_early(struct ucode_cpu_info *uci, bool early)
{
struct microcode_intel *mc;
- u32 rev;
+ u32 rev, prev_rev;
mc = uci->mc;
if (!mc)
return 0;
+ prev_rev = intel_get_microcode_revision();
+
/* write microcode via MSR 0x79 */
native_wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
@@ -596,9 +605,9 @@ static int apply_microcode_early(struct ucode_cpu_info
*uci, bool early)
uci->cpu_sig.rev = rev;
if (early)
- print_ucode(uci);
+ print_ucode(uci, prev_rev);
else
- print_ucode_info(uci, mc->hdr.date);
+ print_ucode_info(uci, mc->hdr.date, prev_rev);
return 0;
}
--
2.16.1
[PATCH] x86/microcode/intel: print previous microcode revision during early update
When kernel do early microcode update, code printing only
new microcode version. But in this case we no have chance
to check which version was in cpu from BIOS vendor.
Patch add this info into output message.
Signed-off-by: Petr Oros
---
arch/x86/kernel/cpu/microcode/intel.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index d9e460fc7a3b..78330d29cd4c 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -515,9 +515,11 @@ static bool load_builtin_intel_microcode(struct cpio_data
*cp)
* Print ucode update info.
*/
static void
-print_ucode_info(struct ucode_cpu_info *uci, unsigned int date)
+print_ucode_info(struct ucode_cpu_info *uci, unsigned int date,
+ unsigned int prev_rev)
{
- pr_info_once("microcode updated early to revision 0x%x, date =
%04x-%02x-%02x\n",
+ pr_info_once("microcode updated early from revision 0x%x to 0x%x, date
= %04x-%02x-%02x\n",
+prev_rev,
uci->cpu_sig.rev,
date & 0x,
date >> 24,
@@ -528,6 +530,7 @@ print_ucode_info(struct ucode_cpu_info *uci, unsigned int
date)
static int delay_ucode_info;
static int current_mc_date;
+static int prev_revision;
/*
* Print early updated ucode info after printk works. This is delayed info
dump.
@@ -538,7 +541,7 @@ void show_ucode_info_early(void)
if (delay_ucode_info) {
collect_cpu_info_early();
- print_ucode_info(, current_mc_date);
+ print_ucode_info(, current_mc_date, prev_revision);
delay_ucode_info = 0;
}
}
@@ -547,11 +550,12 @@ void show_ucode_info_early(void)
* At this point, we can not call printk() yet. Delay printing microcode info
in
* show_ucode_info_early() until printk() works.
*/
-static void print_ucode(struct ucode_cpu_info *uci)
+static void print_ucode(struct ucode_cpu_info *uci, unsigned int prev_rev)
{
struct microcode_intel *mc;
int *delay_ucode_info_p;
int *current_mc_date_p;
+ int *prev_revision_p;
mc = uci->mc;
if (!mc)
@@ -559,13 +563,16 @@ static void print_ucode(struct ucode_cpu_info *uci)
delay_ucode_info_p = (int *)__pa_nodebug(_ucode_info);
current_mc_date_p = (int *)__pa_nodebug(_mc_date);
+ prev_revision_p = (int *)__pa_nodebug(_revision);
*delay_ucode_info_p = 1;
*current_mc_date_p = mc->hdr.date;
+ *prev_revision_p = prev_rev;
}
#else
-static inline void print_ucode(struct ucode_cpu_info *uci)
+static inline void print_ucode(struct ucode_cpu_info *uci,
+ unsigned int prev_rev)
{
struct microcode_intel *mc;
@@ -573,19 +580,21 @@ static inline void print_ucode(struct ucode_cpu_info *uci)
if (!mc)
return;
- print_ucode_info(uci, mc->hdr.date);
+ print_ucode_info(uci, mc->hdr.date, prev_rev);
}
#endif
static int apply_microcode_early(struct ucode_cpu_info *uci, bool early)
{
struct microcode_intel *mc;
- u32 rev;
+ u32 rev, prev_rev;
mc = uci->mc;
if (!mc)
return 0;
+ prev_rev = intel_get_microcode_revision();
+
/* write microcode via MSR 0x79 */
native_wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
@@ -596,9 +605,9 @@ static int apply_microcode_early(struct ucode_cpu_info
*uci, bool early)
uci->cpu_sig.rev = rev;
if (early)
- print_ucode(uci);
+ print_ucode(uci, prev_rev);
else
- print_ucode_info(uci, mc->hdr.date);
+ print_ucode_info(uci, mc->hdr.date, prev_rev);
return 0;
}
--
2.16.1
Re: [PATCH] x86/efi Fix regression in efi_arch_mem_reserve
Matt Fleming píše v Wed 21. 12. 2016 v 22:30 +: > On Wed, 21 Dec, at 02:11:38PM, Petr Oros wrote: > > > > Booting on EFI with ESRT table has been stop since commit: > > 8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() > > > > This is caused by this commit: > > 816e761 efi: Allow drivers to reserve boot services forever > > > > Problem is, that efi_memmap_insert need memory aligned > > on EFI_PAGE_SIZE. If memory not aligned, efi_memmap_insert > > just return and let efi.memmap in inconsistent state. > > This breaking boot. > > > > Tested in my machine, which stop booting > > after upgrade to 4.9 > > > > Signed-off-by: Petr Oros <po...@redhat.com> > > --- > > arch/x86/platform/efi/quirks.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Could you provide some more information? Why does efi_memmap_insert() > require this alignment? How does booting "break"? If you see an Oops, > please post it here. Ooops, sorry, please ignore this patch. I overlooked efi_memmap_insert argument order. I bisected kernel and this patch breaking kernel boot but from other reason. Provided patch fixed kernel booting issue by mistake. -Petr
Re: [PATCH] x86/efi Fix regression in efi_arch_mem_reserve
Matt Fleming píše v Wed 21. 12. 2016 v 22:30 +: > On Wed, 21 Dec, at 02:11:38PM, Petr Oros wrote: > > > > Booting on EFI with ESRT table has been stop since commit: > > 8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() > > > > This is caused by this commit: > > 816e761 efi: Allow drivers to reserve boot services forever > > > > Problem is, that efi_memmap_insert need memory aligned > > on EFI_PAGE_SIZE. If memory not aligned, efi_memmap_insert > > just return and let efi.memmap in inconsistent state. > > This breaking boot. > > > > Tested in my machine, which stop booting > > after upgrade to 4.9 > > > > Signed-off-by: Petr Oros > > --- > > arch/x86/platform/efi/quirks.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Could you provide some more information? Why does efi_memmap_insert() > require this alignment? How does booting "break"? If you see an Oops, > please post it here. Ooops, sorry, please ignore this patch. I overlooked efi_memmap_insert argument order. I bisected kernel and this patch breaking kernel boot but from other reason. Provided patch fixed kernel booting issue by mistake. -Petr
[PATCH] x86/efi Fix regression in efi_arch_mem_reserve
Booting on EFI with ESRT table has been stop since commit:
8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()
This is caused by this commit:
816e761 efi: Allow drivers to reserve boot services forever
Problem is, that efi_memmap_insert need memory aligned
on EFI_PAGE_SIZE. If memory not aligned, efi_memmap_insert
just return and let efi.memmap in inconsistent state.
This breaking boot.
Tested in my machine, which stop booting
after upgrade to 4.9
Signed-off-by: Petr Oros <po...@redhat.com>
---
arch/x86/platform/efi/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 10aca63..7678857 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -214,7 +214,7 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
new_size = efi.memmap.desc_size * num_entries;
- new_phys = memblock_alloc(new_size, 0);
+ new_phys = memblock_alloc(new_size, EFI_PAGE_SIZE);
if (!new_phys) {
pr_err("Could not allocate boot services memmap\n");
return;
--
2.10.2
[PATCH] x86/efi Fix regression in efi_arch_mem_reserve
Booting on EFI with ESRT table has been stop since commit:
8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()
This is caused by this commit:
816e761 efi: Allow drivers to reserve boot services forever
Problem is, that efi_memmap_insert need memory aligned
on EFI_PAGE_SIZE. If memory not aligned, efi_memmap_insert
just return and let efi.memmap in inconsistent state.
This breaking boot.
Tested in my machine, which stop booting
after upgrade to 4.9
Signed-off-by: Petr Oros
---
arch/x86/platform/efi/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 10aca63..7678857 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -214,7 +214,7 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
new_size = efi.memmap.desc_size * num_entries;
- new_phys = memblock_alloc(new_size, 0);
+ new_phys = memblock_alloc(new_size, EFI_PAGE_SIZE);
if (!new_phys) {
pr_err("Could not allocate boot services memmap\n");
return;
--
2.10.2
[PATCH] Documentation: incorrect formula to calculate CommitLimit value
The formula to calculate "CommitLimit" value mentioned in kernel documentation
is incorrect.
Right formula is: CommitLimit = ([total RAM pages] - [total huge TLB pages]) *
overcommit_ratio / 100 + [total swap pages]
Signed-off-by: Petr Oros
---
Documentation/filesystems/proc.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index 8b9cd8e..b58d764 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -854,7 +854,8 @@ WritebackTmp: Memory used by FUSE for temporary writeback
buffers
if strict overcommit accounting is enabled (mode 2 in
'vm.overcommit_memory').
The CommitLimit is calculated with the following formula:
- CommitLimit = ('vm.overcommit_ratio' * Physical RAM) + Swap
+ CommitLimit = ([total RAM pages] - [total huge TLB pages]) *
+ overcommit_ratio / 100 + [total swap pages]
For example, on a system with 1G of physical RAM and 7G
of swap with a `vm.overcommit_ratio` of 30 it would
yield a CommitLimit of 7.3G.
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: incorrect formula to calculate CommitLimit value
The formula to calculate CommitLimit value mentioned in kernel documentation
is incorrect.
Right formula is: CommitLimit = ([total RAM pages] - [total huge TLB pages]) *
overcommit_ratio / 100 + [total swap pages]
Signed-off-by: Petr Oros po...@redhat.com
---
Documentation/filesystems/proc.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index 8b9cd8e..b58d764 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -854,7 +854,8 @@ WritebackTmp: Memory used by FUSE for temporary writeback
buffers
if strict overcommit accounting is enabled (mode 2 in
'vm.overcommit_memory').
The CommitLimit is calculated with the following formula:
- CommitLimit = ('vm.overcommit_ratio' * Physical RAM) + Swap
+ CommitLimit = ([total RAM pages] - [total huge TLB pages]) *
+ overcommit_ratio / 100 + [total swap pages]
For example, on a system with 1G of physical RAM and 7G
of swap with a `vm.overcommit_ratio` of 30 it would
yield a CommitLimit of 7.3G.
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
