Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set_validation_data register weight manually, do not use refund when the pre dispatch is zero. #7327

Merged
merged 8 commits into from
Jan 25, 2025

Conversation

gui1117
Copy link
Contributor

@gui1117 gui1117 commented Jan 24, 2025

Related #6772

For an extrinsic, in the post dispatch info, the actual weight is only used to reclaim unused weight. If the actual weight is more than the pre dispatch weight, then the extrinsic is using the minimum, e.g., the weight used registered in pre dispatch.

In parachain-system pallet one call is set_validation_data. This call is returning an actual weight, but the pre-dispatch weight is 0.

This PR fix the disregard of actual weight of set_validation_data by registering it manually.

@gui1117
Copy link
Contributor Author

gui1117 commented Jan 24, 2025

/cmd prdoc --audience runtime-dev

Copy link
Contributor

Command "prdoc --audience runtime-dev" has failed ❌! See logs here

@gui1117 gui1117 requested a review from skunert January 24, 2025 14:37
@gui1117 gui1117 added the T2-pallets This PR/Issue is related to a particular pallet. label Jan 24, 2025
@gui1117 gui1117 requested a review from athei January 24, 2025 14:40
Copy link
Member

@athei athei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. I can confirm that the try-runtime errors are gone.

@@ -692,7 +692,12 @@ pub mod pallet {
vfp.relay_parent_number,
));

Ok(PostDispatchInfo { actual_weight: Some(total_weight), pays_fee: Pays::No })
frame_system::Pallet::<T>::register_extra_weight_unchecked(
total_weight,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume we don't know an upper bound for this value pre-dispatch because it is calculated ad-hoc?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but it's once per block and we register the weight, meaning it will be correctly accounted for in the following transactions.

If we go with the worst case weight here before dispatching, we might greatly underestimate the block space we have since those stuctures in ParachainInherentData can grow a lot as far as I'm aware. This model works best IMO.

DispatchClass::Mandatory,
);

Ok(Pays::No.into())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: You can change the return type of the dispatchable to just DispatchResult.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in e988d2b

@@ -692,7 +692,12 @@ pub mod pallet {
vfp.relay_parent_number,
));

Ok(PostDispatchInfo { actual_weight: Some(total_weight), pays_fee: Pays::No })
frame_system::Pallet::<T>::register_extra_weight_unchecked(
total_weight,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but it's once per block and we register the weight, meaning it will be correctly accounted for in the following transactions.

If we go with the worst case weight here before dispatching, we might greatly underestimate the block space we have since those stuctures in ParachainInherentData can grow a lot as far as I'm aware. This model works best IMO.

DispatchClass::Mandatory,
);

Ok(Pays::No.into())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make a difference here if we just return this vs Ok(PostDispatchInfo { actual_weight: Some(total_weight), pays_fee: Pays::No })? It would look more correct to me

Copy link
Member

@athei athei Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is what we were doing before (this PR removes this line) and it was incorrect. This is because you cant (or should not) return a post dispatch weight that is higher than the pre dispatch weight. It will not be charged. Hence the error that was emitted by try runtime.

@skunert
Copy link
Contributor

skunert commented Jan 24, 2025

This indeed gets rid of the message for set_validation_data. Another annoyance is that we also see the message on the relay chain:

2025-01-24 17:42:54.008 ERROR ⋮runtime::frame-support: [early-airport-4761] Post dispatch weight is greater than pre dispatch weight. Pre dispatch weight may underestimating the actual weight. Greater post dispatch weight components are ignored.
					Pre dispatch weight: Weight { ref_time: 15254022361, proof_size: 879 },
					Post dispatch weight: Weight { ref_time: 4812758536, proof_size: 37021 }    

Here only the proof_size is larger, but relay chain does not care about it and the limit is u64::max. This is new since the print went from the storage weight reclaim extension to here:

log::error!(
target: crate::LOG_TARGET,
"Post dispatch weight is greater than pre dispatch weight. \
Pre dispatch weight may underestimating the actual weight. \
Greater post dispatch weight components are ignored.
Pre dispatch weight: {info_total_weight:?},
Post dispatch weight: {actual_weight:?}",
);

Maybe we need to move it again so that we can differentiate between para and relaychain.

@athei
Copy link
Member

athei commented Jan 24, 2025

Do you know which dispatchable is causing that? We can just give it the same treatment. Or if it is a pallet only used on the relay chain (where PoV doesn't matter) just set pre-dispatch PoV to something super high?

@bkchr
Copy link
Member

bkchr commented Jan 24, 2025

Maybe we need to move it again so that we can differentiate between para and relaychain.

Or do not print it if proof_size is infinite.

@gui1117
Copy link
Contributor Author

gui1117 commented Jan 25, 2025

This is new since the print went from the storage weight reclaim extension to here:

I have kept other logs in storage weight reclaim. I just added this log because it was scary to silently ignoring post dispatch excess weight.

Another annoyance is that we also see the message on the relay chain: [..]

If the pallet is only used in relay chain and we don't want to fix the benchmark or weight calculation for the call, we can also set the proof size in the post info equal to the pre-dispatch info.

@gui1117 gui1117 enabled auto-merge January 25, 2025 01:57
Copy link
Contributor

Command help:
usage: /cmd bench [-h] [--quiet] [--clean] [--image IMAGE]
                  [--runtime [{dev,westend,rococo,asset-hub-westend,asset-hub-rococo,bridge-hub-rococo,bridge-hub-westend,collectives-westend,contracts-rococo,coretime-rococo,coretime-westend,glutton-westend,people-rococo,people-westend} ...]]
                  [--pallet [PALLET ...]] [--fail-fast]

options:
  -h, --help            show this help message and exit
  --quiet               Won't print start/end/failed messages in PR
  --clean               Clean up the previous bot's & author's comments in PR
  --image IMAGE         Override docker image '--image
                        docker.io/paritytech/ci-unified:latest'
  --runtime [{dev,westend,rococo,asset-hub-westend,asset-hub-rococo,bridge-hub-rococo,bridge-hub-westend,collectives-westend,contracts-rococo,coretime-rococo,coretime-westend,glutton-westend,people-rococo,people-westend} ...]
                        Runtime(s) space separated
  --pallet [PALLET ...]
                        Pallet(s) space separated
  --fail-fast           Fail fast on first failed benchmark

**Examples**:
 Runs all benchmarks
 /cmd bench

 Runs benchmarks for pallet_balances and pallet_multisig for all runtimes which have these pallets. **--quiet** makes it to output nothing to PR but reactions
 /cmd bench --pallet pallet_balances pallet_xcm_benchmarks::generic --quiet

 Runs bench for all pallets for westend runtime and fails fast on first failed benchmark
 /cmd bench --runtime westend --fail-fast

 Does not output anything and cleans up the previous bot's & author command triggering comments in PR
 /cmd bench --runtime westend rococo --pallet pallet_balances pallet_multisig --quiet --clean

@paritytech paritytech deleted a comment from github-actions bot Jan 25, 2025
@paritytech paritytech deleted a comment from github-actions bot Jan 25, 2025
@paritytech paritytech deleted a comment from command-bot bot Jan 25, 2025
@gui1117 gui1117 added this pull request to the merge queue Jan 25, 2025
Merged via the queue into master with commit 682f8cd Jan 25, 2025
196 of 206 checks passed
@gui1117 gui1117 deleted the gui-do-not-use-refund-when-not-benchmarked branch January 25, 2025 03:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T2-pallets This PR/Issue is related to a particular pallet.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants