Searched hist:b0a8df5b968e88da6766562930a1aeb37b7be52c (Results 1 – 3 of 3) sorted by relevance
| /openbmc/phosphor-logging/test/openpower-pels/ |
| H A D | repository_test.cpp | diff b0a8df5b968e88da6766562930a1aeb37b7be52c Tue Jul 07 14:41:06 CDT 2020 Matt Spinler <spinler@us.ibm.com> PEL: Implement respository pruning
This adds a prune() public method on the Repository class to remove PELs
down to at most 90% of capacity and then down to 80% of the maximum
number of PELs if there were more than the maximum.
It does the first set of pruning by placing each PEL is one of 4
categories, and then reducing the total size of each category. The
categories are:
* BMC informational PELs - reduced to 15% of max
* BMC non-informational PELs - reduced to 30% of max
* non-BMC informational PELs - reduced to 15% of max
* non-BMC non-informational PELs - reduced to 30% of max
Within each category, PELs are removed oldest first, and also 4 passes
are made through the PELs, only removing PELs that meet a specific
requirement each pass, stopping as soon as the category limit is
reached.
The pass requirements are:
* Pass 1: Only remove HMC acked PELs
* Pass 2: Only remove OS acked PELs
* Pass 3: Only remove host sent PELs
* Pass 4: Remove any PEL
After the 4 passes on the 4 categories are done then the number of PELs
remaining is checked against the maximum number. If it is more than the
maximum, it will remove the PELs down to 80% of that limit using the
same 4 passes as above. This is done to keep the number of PELs down to
a manageable number when there are a lot of small PELs that don't engage
the size based pruning.
The pruning code doesn't just bring the size or number of PELs to just
below their limit, but rather a percentage below, so that it won't get
into a situation where the algorithm has to run on the repository every
single time a PEL is added.
The OpenBMC event log corresponding to the PELs are not removed. That
is left to other code.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I24da611c095fd3b22b6b1ffab52d919cac5f68b4
|
| /openbmc/phosphor-logging/extensions/openpower-pels/ |
| H A D | repository.hpp | diff b0a8df5b968e88da6766562930a1aeb37b7be52c Tue Jul 07 14:41:06 CDT 2020 Matt Spinler <spinler@us.ibm.com> PEL: Implement respository pruning
This adds a prune() public method on the Repository class to remove PELs
down to at most 90% of capacity and then down to 80% of the maximum
number of PELs if there were more than the maximum.
It does the first set of pruning by placing each PEL is one of 4
categories, and then reducing the total size of each category. The
categories are:
* BMC informational PELs - reduced to 15% of max
* BMC non-informational PELs - reduced to 30% of max
* non-BMC informational PELs - reduced to 15% of max
* non-BMC non-informational PELs - reduced to 30% of max
Within each category, PELs are removed oldest first, and also 4 passes
are made through the PELs, only removing PELs that meet a specific
requirement each pass, stopping as soon as the category limit is
reached.
The pass requirements are:
* Pass 1: Only remove HMC acked PELs
* Pass 2: Only remove OS acked PELs
* Pass 3: Only remove host sent PELs
* Pass 4: Remove any PEL
After the 4 passes on the 4 categories are done then the number of PELs
remaining is checked against the maximum number. If it is more than the
maximum, it will remove the PELs down to 80% of that limit using the
same 4 passes as above. This is done to keep the number of PELs down to
a manageable number when there are a lot of small PELs that don't engage
the size based pruning.
The pruning code doesn't just bring the size or number of PELs to just
below their limit, but rather a percentage below, so that it won't get
into a situation where the algorithm has to run on the repository every
single time a PEL is added.
The OpenBMC event log corresponding to the PELs are not removed. That
is left to other code.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I24da611c095fd3b22b6b1ffab52d919cac5f68b4
|
| H A D | repository.cpp | diff b0a8df5b968e88da6766562930a1aeb37b7be52c Tue Jul 07 14:41:06 CDT 2020 Matt Spinler <spinler@us.ibm.com> PEL: Implement respository pruning
This adds a prune() public method on the Repository class to remove PELs
down to at most 90% of capacity and then down to 80% of the maximum
number of PELs if there were more than the maximum.
It does the first set of pruning by placing each PEL is one of 4
categories, and then reducing the total size of each category. The
categories are:
* BMC informational PELs - reduced to 15% of max
* BMC non-informational PELs - reduced to 30% of max
* non-BMC informational PELs - reduced to 15% of max
* non-BMC non-informational PELs - reduced to 30% of max
Within each category, PELs are removed oldest first, and also 4 passes
are made through the PELs, only removing PELs that meet a specific
requirement each pass, stopping as soon as the category limit is
reached.
The pass requirements are:
* Pass 1: Only remove HMC acked PELs
* Pass 2: Only remove OS acked PELs
* Pass 3: Only remove host sent PELs
* Pass 4: Remove any PEL
After the 4 passes on the 4 categories are done then the number of PELs
remaining is checked against the maximum number. If it is more than the
maximum, it will remove the PELs down to 80% of that limit using the
same 4 passes as above. This is done to keep the number of PELs down to
a manageable number when there are a lot of small PELs that don't engage
the size based pruning.
The pruning code doesn't just bring the size or number of PELs to just
below their limit, but rather a percentage below, so that it won't get
into a situation where the algorithm has to run on the repository every
single time a PEL is added.
The OpenBMC event log corresponding to the PELs are not removed. That
is left to other code.
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I24da611c095fd3b22b6b1ffab52d919cac5f68b4
|