[Trainer.py] tr_loss in trainer with distributed training
## Environment info
<!-- You can run the command `transformers-cli env` and copy-and-paste its output below.
     Don't forget to fill out the missing fields in that output! -->

- `transformers` version: 4.4, not very sure
- Platform: linux
- Python version: 3.7
- PyTorch version (GPU?): 1.7
- Tensorflow version (GPU?): //
- Using GPU in script?: Yes
- Using distributed or parallel set-up in script?: Distributed training with single node with multi-gpu

### Who can help
<!-- Your issue will be replied to more quickly if you can figure out the right person to tag with @
 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- albert, bert, xlm: @LysandreJik
- blenderbot, bart, marian, pegasus, encoderdecoder,  t5: @patrickvonplaten, @patil-suraj
- longformer, reformer, transfoxl, xlnet: @patrickvonplaten
- fsmt: @stas00
- funnel: @sgugger
- gpt2: @patrickvonplaten, @LysandreJik
- rag: @patrickvonplaten, @lhoestq
- tensorflow: @Rocketknight1

Library:

- benchmarks: @patrickvonplaten
- deepspeed: @stas00
- ray/raytune: @richardliaw, @amogkam
- text generation: @patrickvonplaten
- tokenizers: @LysandreJik
- trainer: @sgugger
- pipelines: @LysandreJik

Documentation: @sgugger

Model hub:

- for issues with a model report at https://discuss.huggingface.co/ and tag the model's creator.

HF projects:

- datasets: [different repo](https://github.com/huggingface/datasets)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Examples:

- maintained examples (not research project or legacy): @sgugger, @patil-suraj
- research_projects/bert-loses-patience: @JetRunner
- research_projects/distillation: @VictorSanh


 -->
@sgugger 

## Information

Model I am using (Bert, XLNet ...): Bart

The problem arises when using: trainer.py


## To reproduce

Steps to reproduce the behavior:

1. python -m torch.distributed.launch --nproc_per_node=2 xxx
2. observe the tr_loss

<!-- If you have code snippets, error messages, stack traces please provide them here as well.
     Important! Use code tags to correctly format your code. See https://help.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks#syntax-highlighting
     Do not use screenshots, as they are hard to read and (more importantly) don't allow others to copy-and-paste your code.-->

## Expected behavior

<!-- A clear and concise description of what you would expect to happen. -->
I'm not sure if it's a bug or a misunderstanding. In `trainer.py`, the `tr_loss` printed in the distributed training is the loss caused in rank = 0. Do we need to reduce the `tr_loss`?

![image](https://user-images.githubusercontent.com/23735761/122360089-b4c14900-cf88-11eb-9d2d-1e8a5b724a17.png)

Since it's averaged over all the training mini-batches, it should be a good representation of the real training loss. I'd personally avoid any complexity and add a new reduce operation here, since a user can always evaluate on the training set to get the "real" training loss if they absolutely need to. Does that make sense?<|||||>Thank you for your reply. I got it. 